Jelte Fennema-Nio <m...@jeltef.nl> writes: > On Fri, 17 May 2024 at 21:24, Robert Haas <robertmh...@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. 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