On Sat, May 25, 2024 at 6:40 AM Jelte Fennema-Nio <m...@jeltef.nl> wrote: > 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
Yeah. I wonder how Heikki thinks he can do (2) without breaking everything. Maybe just adding an extra, optional, longer field onto the existing message and hoping that client implementations ignore the extra field? If that's not good enough, then I don't understand how that can be done without breaking compatibility in a fundamental and relatively serious way -- at which point maybe bumping the protocol version is the right thing to do. Really, what I'm strongly opposed to is not bumping the version, but rather doing things that break compatibility such that we need to bump the version. *If* we have a problem that's sufficiently serious to justify breaking compatibility anyway, then we don't really lose anything by bumping the version, and indeed we gain something. I just want us to be searching for ways to avoid breaking interoperability, rather than seeking them out. If it becomes impossible for a PG 18 (or whatever version) server to communicate with earlier servers without specifying special options, or worse yet at all, then a lot of people are going to be very sad about that. We will get a bunch of complaints and a bunch of frustrated users, and they will not be impressed by vague claims of necessity or desirability. They'll just be mad. The question for me here is not "what is the theoretically right thing to do?" but rather "what am I going to tell angry users when they demand to know why I committed the patch that broke this?". "The old way was insecure so we had to change it" might be a good enough reason for people to calm down and stop yelling at me, but "it's no use having a protocol version if we never bump it" definitely won't be. -- Robert Haas EDB: http://www.enterprisedb.com
