Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs - Mailing list pgsql-hackers
From | Dave Cramer |
---|---|
Subject | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
Date | |
Msg-id | CADK3HH+gaap8i5r8J=kMwXmdXzVXOA7kbs=SZdyXn0kpdExn_w@mail.gmail.com Whole thread Raw |
In response to | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs (Jelte Fennema-Nio <me@jeltef.nl>) |
List | pgsql-hackers |
On Sat, 25 May 2024 at 06:40, Jelte Fennema-Nio <me@jeltef.nl> wrote:
On Thu, 23 May 2024 at 20:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Jelte Fennema-Nio <me@jeltef.nl> writes:
> > On Fri, 17 May 2024 at 21:24, Robert Haas <robertmhaas@gmail.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.
I'm not necessarily super opposed to only using the _pq_.xxx
mechanism.
I find it interesting that up to now nobody has ever used this mechanism.
I mainly think it's silly to have a protocol version number
and then never use it. And I feel some of the proposed changes don't
really benefit from being able to be turned on-and-off by themselves.
My rule of thumb would be:
1. Things that a modern client/pooler would always request: version bump
2. Everything else: _pq_.xxx
Have to agree, why have a protocol version and then just not use it ?
Of the proposed changes so far on the mailing list the only 2 that
would fall under 1 imho are:
1. The ParameterSet message
2. Longer than 32bit secret in BackendKeyData
I also don't think the GIF situation you describe translates fully to
this discussion. We have active protocol version negotiation, so if a
server doesn't support protocol 3.1 a client is expected to fall back
to the 3.0 protocol when communicating.
Also agree. Isn't the point of having a version number to figure out what features the client wants and subsequently the server can provide?
Of course you can argue that a
badly behaved client will fail to connect when it gets a downgrade
request from the server, but that same argument can be made about a
server not reporting support for a _pq_.xxx parameter that every
modern client/pooler requests. So I don't think there's a practical
difference in the problem you're describing.
+1
But again if I'm alone in this, then I don't
I would prefer to see a well defined protocol handshaking mechanism rather than some strange _pq.xxx dance.
Dave
pgsql-hackers by date: