On Mon, 15 Apr 2024 at 15:38, Jelte Fennema-Nio <me@jeltef.nl> wrote:
On Mon, 15 Apr 2024 at 19:43, Robert Haas <robertmhaas@gmail.com> wrote: > > On Sat, Apr 6, 2024 at 6:14 PM Jelte Fennema-Nio <me@jeltef.nl> wrote: > > I think for clients/drivers, the work would generally be pretty > > minimal. For almost all proposed changes, clients can "support" the > > protocol version update by simply not using the new features, ... > > I mean, I agree if a particular protocol version bump does nothing > other than signal the presence of some optional, ignorable feature, > then it doesn't cause a problem if we force clients to support it. But > that seems a bit like saying that eating wild mushrooms is fine > because some of them aren't poisonous. The point is that if we roll > out two protocol changes, A and B, each of which requires the client > to make some change in order to work with the newer protocol version, > then using version numbers as the gating mechanism requires that the > client can't support the newer of those two changes without also > supporting the older one. Using feature flags doesn't impose that > constraint, which I think is a plus.
I think we're in agreement here, i.e. it depends on the situation if a feature flag or version bump is more appropriate. I think the guidelines could be as follows: 1. For protocol changes that require "extremely minimal" work from clients & poolers: bump the protocol version. 2. For "niche" features that require some work from clients and/or poolers: use a protocol parameter feature flag. 3. For anything in between, let's discuss on the thread for that specific protocol change on the tradeoffs.
My first thought here is that all of the above is subjective and we will end up discussing all of the above.
No real argument just an observation.
On Mon, 15 Apr 2024 at 19:52, Robert Haas <robertmhaas@gmail.com> wrote: > surely it can't be right to use protocol > version 3.0 to refer to a bunch of different things. But at the same > time, surely we don't want clients to start panicking and bailing out > when everything would have been fine.
I feel like the ProtocolVersionNegotiation should make sure people don't panic and bail out. And if not, then feature flags won't help with this either. Because clients would then still bail out if some feature is not supported.
I don't think a client should ever bail out. They may not support something but IMO bailing out is not an option.
