On 29 June 2017 at 20:18, Robert Haas <robertmh...@gmail.com> wrote: > 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.
We probably also need to be able to differentiate between "this protocol option would be nice if you support it, please tell me in your parameter status message if you managed to honour it" vs "this connection request is invalid if you cannot honour this protocol option, do not attempt to proceed". If the option changes the meaning of the request entirely in some way we probably don't want a server that doesn't understand carrying on anyway. But I think it's probably sufficient if the server's reply to the client includes the options it was able to recognise and honour, so the client can immediately nope out if it doesn't like the server's lack of support for some option. > 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: Yes, but something shorter probably, Tom's already expressed concerns elsewhere about bandwidth use from reporting server_version_num and I can't imagine numerous pg_protocol_blahblah entries being popular with many people at all. _pg_... seems sufficient IMO, we don't use that in GUCs to date, and nobody's likely to. Or to be consistent with protocol and libpq stuff, _pq_... ? > 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. Not a fan of bumping for the sake of it, it puts more work on 3rd party drivers for what seems like no real gain. Bump when we change something. > 2. If the client version is anything other than 3.0, the server > responds with a ServerProtocolVersion indicating the highest version > it supports Highest and lowest, I think Satyanarayana Narlapuram is right there. Also which startup parameter protocol options were recognised and honoured, so the client can immediately notice and bail if the server didn't recognise something it requires. (think behaviour akin to sslmode=require for _pg_starttls). > and ignores any pg_protocol.<whatever> options not known > to it as being either third-party extensions or something from a > future version. I think ignoring is fine if the server lists the ones it recognises in its reply, per above. > 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.) Such a backpatch makes sense, and is pretty safe. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers