On Sat, May 25, 2024 at 6:40 AM Jelte Fennema-Nio <me@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
