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

Jacob Champion <jacob.champion@enterprisedb.com>

From: Jacob Champion <jacob.champion@enterprisedb.com>

To: Jelte Fennema-Nio <postgres@jeltef.nl>

Cc: Robert Haas <robertmhaas@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Tom Lane <tgl@sss.pgh.pa.us>, Jacob Burroughs <jburroughs@instructure.com>, Dave Cramer <davecramer@gmail.com>, Peter Smith <smithpb2250@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Pavel Stehule <pavel.stehule@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Peter Eisentraut <peter@eisentraut.org>, Daniele Varrazzo <daniele.varrazzo@gmail.com>

Date: 2024-08-20T13:48:00Z

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 →

libpq: Add min/max_protocol_version connection options
- 285613c60a7a 18.0 landed
libpq: Handle NegotiateProtocolVersion message differently
- 5070349102af 18.0 landed
Add PQfullProtocolVersion() to surface the precise protocol version.
- cdb6b0fdb0b2 18.0 landed
Do not hardcode PG_PROTOCOL_LATEST in NegotiateProtocolVersion
- 516b87502dc1 18.0 landed
libpq: Handle NegotiateProtocolVersion message
- bbf9c282ce92 16.0 cited
Provide for forward compatibility with future minor protocol versions.
- ae65f6066dc3 11.0 cited

On Mon, Aug 19, 2024 at 1:54 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> My point is that the code that breaks, actually wants to be broken in this case.

I'll turn this around then and assume for a moment that this is true:
no matter what the use cases are, they all want to be broken for
correctness. If this version change is allowed to break both the
endpoints and any intermediaries on the connection, why have we chosen
30001 as the new reported version as opposed to, say, 4?

Put another way: for a middlebox on the connection (which may be
passively observing, but also maybe actively adding new messages to
the stream), what is guaranteed to remain the same in the protocol
across a minor version bump? Hopefully the answer isn't "nothing"?

--Jacob