On Thu, 4 Apr 2024 at 12:45, Jelte Fennema-Nio <me@jeltef.nl> wrote:
On Thu, 4 Apr 2024 at 14:50, Peter Eisentraut <peter@eisentraut.org> wrote: > It appears there are several different perspectives about this. My > intuition was that a protocol version change indicates something that we > eventually want all client libraries to support. Whereas protocol > extensions are truly opt-in. > > For example, if we didn't have the ParameterStatus message and someone > wanted to add it, then this ought to be a protocol version change, so > that we eventually get everyone to adopt it. > > But, for example, the column encryption feature is not something I'd > expect all client libraries to implement, so it can be opt-in.
I think that is a good way of deciding between version bump vs protocol extension parameter. But I'd like to make one clarification/addition to this logic, if the protocol feature already requires opt-in from the client because of how the feature works, then there's no need for a protocol extension parameter. e.g. if you're column-encryption feature would require the client to send a ColumnDecrypt message before the server would exhibit any behaviour relating to the column-encryption feature, then the client can simply "support" the feature by never sending the ColumnDecrypt message. Thus, in such cases a protocol extension parameter would not be necessary, even if the feature is considered opt-in.
> (I believe we have added a number of new protocol messages since the > beginning of the 3.0 protocol, without any version change, so "new > protocol message" might not always be a good example to begin with.)
Personally, I feel like this is something we should change. IMHO, we should get to a state where protocol minor version bumps are so low-risk that we can do them whenever we add message types. Right now there are basically multiple versions of the 3.0 protocol, which is very confusing to anyone implementing it. Different servers implementing the 3.0 protocol without the NegotiateVersion message is a good example of that.
Totally agree.
> I fear that if we prefer protocol extensions over version increases, > then we'd get a very fragmented landscape of different client libraries > supporting different combinations of things.