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

From Craig Ringer
Subject Re: NOT EXIST for PREPARE
Date
Msg-id CAMsr+YEibRqbwGrEASpRHviNz5pJFU9gxC7qA+hysxY9NokmSw@mail.gmail.com
Whole thread Raw
In response to Re: NOT EXIST for PREPARE  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
List pgsql-hackers
On 24 March 2016 at 23:13, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:

>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?

(Kinda a side-track, but):

Because that's too late. When we eventually do a v4 protocol it needs a way to say, during initial handshake, what the server and client support, so the server won't send any protocol messages to the client that it can't understand and vice versa. 

The simplest form is "I <server> speak protocol 4.4", "I <client> speak protocol 4.1", "OK, lets use protocol 4.1 and the server won't send you anything that might confuse you from 4.2, 4.3, or 4.4."

Much better is for the client to connect with "I <client> understand GSSAPI, lazily fetched LOBs, STARTTLS, and wire-level compression" and the server to say "I understand GSSAPI, wire-level compression, per-datum charsets and database-switching", so they know to agree on using GSSAPI and wire-level compression. Neither will send the other stuff it won't understand that could land up breaking it.

Right now we've really got no way to add additional data to query responses, commandcomplete, etc, because we've got no way to make sure the client can cope with it being there.

See also https://wiki.postgresql.org/wiki/Todo#Wire_Protocol_Changes

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: VS 2015 support in src/tools/msvc
Next
From: Craig Ringer
Date:
Subject: Re: 2PC support for pglogical