Re: NOT EXIST for PREPARE

Поиск
Список
Период
Сортировка
От Vladimir Sitnikov
Тема Re: NOT EXIST for PREPARE
Дата
Msg-id CAB=Je-FQPhjawNmETd7q1Gwv8O5eJ2x=2a-OJf+Jb9omJnT0kQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: NOT EXIST for PREPARE  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: NOT EXIST for PREPARE  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: NOT EXIST for PREPARE  (Craig Ringer <craig@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Robbie Harwood
Дата:
Сообщение: Re: BUG #13854: SSPI authentication failure: wrong realm name used
Следующее
От: Robert Haas
Дата:
Сообщение: Re: dealing with extension dependencies that aren't quite 'e'