On Thu, Apr 18, 2024 at 5:36 PM Jelte Fennema-Nio <m...@jeltef.nl> wrote: > To clarify: My proposed approach is to use a protocol extension > parameter for to enable the new messages that the server can send > (like Peter is doing now). And **in addition to that** gate the new > Bind format type behind a feature switch. There is literally nothing > clients will have to do to "support" that feature (except for > requesting a higher version protocol). Your suggestion of not bumping > the version but still allowing the new format type on version 3.0 > doesn't have any advantage afaict, except secretly hiding from any > pooler in the middle that such a format type might be sent.
That's a fair point, but I'm still not seeing much practical advantage. It's unlikely that a client is going to set a random bit in a format parameter for no reason. > As a connection pooler maintainer I would definitely love it if every > protocol change required either a protocol version parameter or a > protocol version bump. That way I can easily check every release if > the protocol changed by looking at two things, instead of diffing the > protocol docs for some tiny "supposedly irrelevant" change was made. Perhaps this is the root of our disagreement, or at least part of it. I completely agree that it is important for human beings to be able to understand whether, and how, the wire protocol has changed from one release to another. I think it would be useful to document that, and maybe some agreement to start actually bumping the version number would come out of that, either immediately or eventually. But I don't think bumping the protocol version first is going to help anything. If you know that something has changed at least one time in the release, you still have to figure out what it was, and whether there were any more of them that, presumably, would not bump the protocol version because there would be no good reason to do that more than once per major release. Not only that, but it's entirely possible that someone could fail to realize that they were supposed to bump the protocol version, or have some reason not to do it in a particular instance, so even if there are no bumps at all in a particular release cycle, that doesn't prove that there are no changes that you would have liked to know about. Said differently, I think bumping the protocol version should be, first and foremost, a way of telling the computer on the end of the connection something that it needs to know. There is a separate problem of making sure that human maintainers know what they need to know, and I think we're doing that quite poorly right now, but I think you might be conflating those two problems a bit. -- Robert Haas EDB: http://www.enterprisedb.com
