Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

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-8e4b2d89d88f(at)enterprisedb(dot)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.