Re: protocol version negotiation (Re: Libpq PGRES_COPY_BOTH - version compatibility)

On Wed, Jun 28, 2017 at 10:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yeah.  Back in the day I helped design the PNG image format, and one
> of the better ideas in it was to make a distinction between critical and
> noncritical chunks within a PNG file; that was exactly the idea you're
> getting at here.  I agree with the suggestion to drive this off a
> parameter-name-based convention.  Having leading underscore indicate
> a noncritical parameter sounds fine.

I'm not sure if non-critical is exactly the right terminology.  What
we want to do is distinguish between things that are intended as
protocol-level options vs. things that are intended as GUCs.  Of
course, there's nothing that actually prevents a a GUC from starting
with an underscore:

rhaas=# set _foo._bar = 1;
SET

Maybe we should instead pick a GUC namespace and reserve it for the
use of protocol level options; e.g. pg_protocol.<anything> becomes
invalid as the name of a GUC, but can be included in a startup packet
(or do we need to pick something shorter, like _pg, to keep the
message short?).  Servers ignore anything that they don't understand.
So:

1. The client sends a StartupMessage 3.x for version 3.x.  We could
bump the version explicitly, or perhaps we should just coin a version
of libpq for every server release; e.g. whatever PostgreSQL 11 ships
is version 3.11, etc.  It includes any protocol options that don't
exist today as pg_protocol.<whatever> in the startup packet.

2. If the client version is anything other than 3.0, the server
responds with a ServerProtocolVersion indicating the highest version
it supports, and ignores any pg_protocol.<whatever> options not known
to it as being either third-party extensions or something from a
future version.  If the initial response to the startup message is
anything other than a ServerProtocolVersion message, the client should
assume it's talking to a 3.0 server.  (To make this work, we would
back-patch a change into existing releases to allow any 3.x protocol
version and ignore any pg_protocol.<whatever> options that were
specified.)

If either the client or the server is unhappy about the age of the
other, then it can disconnect; e.g. if the server is configured to
require the use of whizzbang-2 security, and the client protocol
version indicates that at most whizzbang-1.9 is available, then the
server can close the connection with a suitable complaint; conversely,
if the connection string had require_whizzbang=2, and the server is
too old to support that, then the client can decide to bail out when
it receives the ServerProtocolVersion message.

Still just thinking out loud here.  Thoughts?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company