On Thu, 4 Apr 2024 at 12:45, Jelte Fennema-Nio <m...@jeltef.nl> wrote:
> On Thu, 4 Apr 2024 at 14:50, Peter Eisentraut <pe...@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. > > +1 Dave > +1 >
