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

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

To: Heikki Linnakangas <hlinnaka@iki.fi>

Cc: Jacob Champion <jacob.champion@enterprisedb.com>, Jelte Fennema-Nio <postgres@jeltef.nl>, 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-20T15:45:58Z

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 Tue, Aug 20, 2024 at 11:24 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> That's not a completely crazy idea, it crossed my mind too. And since we
> already decided to skip protocol number 3.1, how about we jump directly
> to 3.4. That way:
>
> protocol |
>   version | PQProtocolVersion()
>
>         2 | 2   (in old unsupported library versions)
>       3.0 | 3
>       3.4 | 4
>       3.5 | 5
>
> and so forth.
>
> This kind of assumes we'll never bump the major protocol version again.
> But if we do, we could jump to 40000 at that point.

I personally like this less than both (a) adding a new function and
(b) redefining the existing function as Jelte proposes. It just seems
too clever to me.

-- 
Robert Haas
EDB: http://www.enterprisedb.com