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

Jelte Fennema-Nio <me(at)jeltef(dot)nl> writes:
> On Fri, 17 May 2024 at 21:24, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Perhaps these are all minority positions, but I can't tell you what
>> everyone thinks, only what I think.

> I'd love to hear some opinions from others on these design choices. So
> far it seems like we're the only two that have opinions on this (which
> seems hard to believe) and our opinions are clearly conflicting. And
> above all I'd like to move forward with this, be it my way or yours
> (although I'd prefer my way of course ;) )

I got around to looking through this thread in preparation for next
week's patch review session. I have a couple of opinions to offer:

1. Protocol versions suck. Bumping them is seldom a good answer,
and should never be done if you have any finer-grained negotiation
mechanism available. My aversion to this is over thirty years old:
I learned that lesson from watching the GIF87-to-GIF89 transition mess.
Authors of GIF-writing tools tended to take the easy way out and write
"GIF89" in the header whether they were actually using any of the new
version's features or not. This led to an awful lot of pictures that
couldn't be read by available GIF-displaying tools, for no good reason
whatsoever. The PNG committee, a couple years later, reacted to that
mess by designing PNG to have no version number whatsoever, and yet
be extensible in a fine-grained way. (Basically, a PNG file is made
up of labeled chunks. If a reader doesn't recognize a particular
chunk code, it can still tell whether the chunk is "critical" or not,
and thereby decide if it must give up or can proceed while ignoring
that chunk.)

So overall, I have a strong preference for using the _pq_.xxx
mechanism instead of a protocol version bump. I do not believe
the latter has any advantage.

2. I share Robert's suspicion of equating protocol parameters
with GUCs. The GUC mechanism is quite opinionated and already
serves multiple masters. In particular, the fact that GUC
settings are normally transactional does not play nice with
the way protocol parameters need to behave. Yeah, no doubt you
could add another dollop of complexity to guc.c to make parameters
work differently from other GUCs, but I think it's the wrong design
direction. We should handle protocol parameters with a separate
mechanism. It's not, for instance, clear to me that protocol
parameters should be exposed at the SQL level at all; but if we
don't feel they need to be available via SHOW and pg_settings,
what benefit is guc.c really bringing to the table?

regards, tom lane