On Sat, 25 May 2024 at 06:40, Jelte Fennema-Nio <m...@jeltef.nl> wrote:
> On Thu, 23 May 2024 at 20:12, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > 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. > > 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