Re: NOT EXIST for PREPARE - Mailing list pgsql-hackers

From Vladimir Sitnikov
Subject Re: NOT EXIST for PREPARE
Date
Msg-id CAB=Je-FQPhjawNmETd7q1Gwv8O5eJ2x=2a-OJf+Jb9omJnT0kQ@mail.gmail.com
Whole thread Raw
In response to Re: NOT EXIST for PREPARE  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: NOT EXIST for PREPARE
Re: NOT EXIST for PREPARE
List pgsql-hackers
Craig>I really, really doubt you can change this before we do a
protocol version bump.

Technically speaking, the idea of using first bytes of statement name
to convey extra information does not require protocol version bump. It
can be backward and forward compatible.

For instance: if statement name starts with __, then skip throwing an
error if statement with exactly same text and parameter types has
already been prepared.

by "prepare ..." below I mean v3 prepare message, not "prepare sql" command.

prepare __s1(int) select $1; -> prepared
prepare __s1(int) select $1; -> prepared, no error since statement
name starts with __
prepare s1(int) select $1; -> prepared
prepare s1(int) select $1; -> error "statement s1 has already been used"

>doesn't have any kind of capabilities negotiation

Do you think capability negotiation should indeed be at the protocol level?
What's wrong with say "select * from backend_capabilities" at the
connection setup?

Vladimir



pgsql-hackers by date:

Previous
From: Robbie Harwood
Date:
Subject: Re: BUG #13854: SSPI authentication failure: wrong realm name used
Next
From: Robert Haas
Date:
Subject: Re: dealing with extension dependencies that aren't quite 'e'