On 14.03.24 21:33, Robert Haas wrote:
You seem to be supposing here that all protocol changes will consist of adding new message types. While I think that will be a common pattern, I do not think it will be a universal one.
As an additional data point, the column encryption patch that is currently on hiatus [0] uses a protocol extension to change the format of existing message types.
[0]: https://www.postgresql.org/message-id/flat/89157929-c2b6-817b-6025-8e4b2d89d...@enterprisedb.com
This is definitely not how I was thinking about it. I was imagining that we wanted to reserve bumping the protocol version for more significant changes, and that we'd use _pq_ parameters for relatively minor new functionality whether Boolean-valued or otherwise.
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 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.)
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.
