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

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

> On Tue, Aug 20, 2024 at 12:42 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > I'm wondering why we are indicating that minor versions of the protocol
> are even a real thing.
>
> Because that concept is already a part of the existing wire protocol.
>
>
Right...

"
If the major version requested by the client is not supported by the
server, the connection will be rejected ... If the minor version requested
by the client is not supported by the server ... the server may either
reject the connection or may respond with a NegotiateProtocolVersion
message containing the highest minor protocol version which it supports.
The client may then choose either to continue with the connection using the
specified protocol version or to abort the connection.
"

So basically my proposal amounted to making every update a "major version
update" and changing the behavior surrounding NegotiateProtocolVersion so
it applies to major version differences. I'll stand by that change in
definition. The current one doesn't seem all that useful anyway, and as we
only have a single version, definitely hasn't been materially implemented.
Otherwise, at some point a client that knows both v3 and v4 will exist and
its connection will be rejected instead of downgraded by a v3-only server
even though such a downgrade would be possible. I suspect we'd go ahead
and change the rule then - so why not just do so now, while getting rid of
the idea that minor versions are a thing.

I suppose we could leave minor versions for patch releases of the main
server version - which still leaves the first new feature of a release
incrementing the major version. That would be incidental to changing how
we handle major versions.

David J.