From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Yury Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: NOT EXIST for PREPARE |
Date: | 2016-03-24 15:13:05 |
Message-ID: | CAB=Je-FQPhjawNmETd7q1Gwv8O5eJ2x=2a-OJf+Jb9omJnT0kQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-03-24 15:14:56 | Re: dealing with extension dependencies that aren't quite 'e' |
Previous Message | Robbie Harwood | 2016-03-24 15:07:16 | Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used |