Horton

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

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: Robert Haas <robertmhaas@gmail.com>, Jelte Fennema-Nio <me@jeltef.nl>
Cc: Peter Smith <smithpb2250@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Jacob Burroughs <jburroughs@instructure.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Dave Cramer <davecramer@gmail.com>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Pavel Stehule <pavel.stehule@gmail.com>, Jeff Davis <pgsql@j-davis.com>
Date: 2024-04-04T12:50:27Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. libpq: Add min/max_protocol_version connection options

  2. libpq: Handle NegotiateProtocolVersion message differently

  3. Add PQfullProtocolVersion() to surface the precise protocol version.

  4. Do not hardcode PG_PROTOCOL_LATEST in NegotiateProtocolVersion

  5. libpq: Handle NegotiateProtocolVersion message

  6. Provide for forward compatibility with future minor protocol versions.

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@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.