On Mon, 15 Apr 2024 at 15:38, Jelte Fennema-Nio <m...@jeltef.nl> wrote:
> On Mon, 15 Apr 2024 at 19:43, Robert Haas <robertmh...@gmail.com> wrote: > > > > On Sat, Apr 6, 2024 at 6:14 PM Jelte Fennema-Nio <m...@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 <robertmh...@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. Dave > >
