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

On Tue, Aug 20, 2024 at 10:03 AM Jacob Champion <
jacob(dot)champion(at)enterprisedb(dot)com> wrote:

> On Tue, Aug 20, 2024 at 7:26 AM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
> wrote:
> > In practical terms I think that means for a minor version bump the
> > format of the StartupMessage cannot be changed. Changing anything else
> > is fair game for a minor protocol version bump.
>
> I may be in a tiny minority here, but when I combine that statement
> with your opinion from way upthread that
>
> > IMHO, we
> > should get to a state where protocol minor version bumps are so
> > low-risk that we can do them whenever we add message types
>
> To me it seems that what you're proposing is indistinguishable from
> what most other protocols would consider a major version bump; it's
> just that you (reasonably) want existing clients to be able to
> negotiate multiple major versions in one round trip.
>
>
This makes more sense to me - a major version change is one where the
server fails to understand the incoming message(s) to the point that it
cannot make decisions based upon contents.

Framed up this way the two-part versioning works just fine and I concur
that PQversionNumber should go ahead and report 10000+minor (starting at 2)
with 3.0 remaining as-is since apparently negotiation down to 3.0 is
possible here if the intermediate and/or final server have such ability.

Still, instead of just failing immediately if 30002 is specified and
rejected, falling back to trying 3.0 - unless configured to either not do
that or to only do 3.0 - is advised to help with the transition.

David J.