Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

On Tue, Aug 20, 2024 at 9:02 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> Yes. And the major * 10000 + minor convention is used in other places
> already, for PG versions, so it might already be familiar to some
> people.
>

I'm wondering why we are indicating that minor versions of the protocol are
even a real thing. We should just use integer version numbers. We are on
3. The next one is 4 (the trailing .0 is just historical cruft just like
with our 3-digit PostgreSQL version number).

v18 libpq-based clients, if they attempt to connect using v4 and fail, will
try again using the v3 connection. That will retain status quo behavior
when something like a connection pooler doesn't understand the new
reality. We can add a libpq option to prevent this auto-downgrade behavior.

At some point users will want to use something other than the v3 current
tooling supports and will put pressure on those tools to change. In the
mean-time our out-of-the-box behavior continues to work using the v3
protocol.

Feature detection sounds great, and maybe we want to go there eventually,
but everyone understands progressive enhancement represented by version
numbering. A given major server version would only support a fixed and
unchanging set of protocol versions between 3 and N. On the client, if N =
7 then libpq would be able to choose both 7 and 3 as the version it tries
out-of-the-box. We can use a libpq parameter to allow the client to
specify something between 4 and 6 (which may fail depending on poolers and
what-not). If the chain of servers supports protocol version negotiation
then the attempt to connect using 7 can be auto-downgraded to anything
between 3 and 6 (saving effort of a failed attempt and establishing a new
one.) Leaving the client the option to specify a minimum version of the
protocol it can accept.

David J.