On Mon, 15 Apr 2024 at 21:47, Dave Cramer <davecra...@gmail.com> wrote: >> 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.
On Thu, 18 Apr 2024 at 21:01, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Apr 18, 2024 at 1:49 PM Jelte Fennema-Nio <postg...@jeltef.nl> wrote: > > IMHO that means that we should also bump the protocol version for this > > change, because it's changing the wire protocol by adding a new > > parameter format code. And it does so in a way that does not depend on > > the new protocol extension. > > I think we're more or less covering the same ground we did on the > other thread here -- in theory I don't love the fact that we never > bump the protocol version when we change stuff, but in practice if we > start bumping it every time we do anything I think it's going to just > break a bunch of stuff without any real benefit. (the second quoted message comes from Peter his column encryption thread, but responding here to keep this discussion in one place) I really don't understand what exactly you're worried about. What do you expect will break when bumping the protocol version? As Dave said, clients should never bail out due to protocol version differences. When the server supports a lower version than the client, the client should disable certain features because it gets the ProtocolVersionNegotiation message. This is also true if we don't bump the version. Negotiating a lower version actually makes it clearer for the client what features to disable. Using the reported postgres version for this might not, because a connection pooler in the middle might not support the features that the client wants and thus throw an error (e.g. due to the client sending unknown messages) even if the backing Postgres server would support these features. Not to mention non-postgresql servers that implement the PostgreSQL protocol (of which there are more and more). When the server supports a higher version, the client never even notices this because the server will silently accept and only enable the features of the lower version. So this could never cause breakage, as from the client's perspective the server didn't bump their protocol version. So, I don't understand why you seem to view bumping the protocol version with so much negativity. We're also bumping PG versions every year. Afaik people only like that, partially because it's immediately clear that certain features (e.g. MERGE) are not supported when connecting to older servers. To me the same is true for bumping the protocol version. There are no downsides to bumping it, only upsides.
