Re: NOT EXIST for PREPARE

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

In response to

Responses

Browse pgsql-hackers by date

  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