On Wed, Jun 28, 2017 at 10:27 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers