Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Jacob Champion <jacob.champion@enterprisedb.com>, 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-20T16:02:34Z
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 Tue, Aug 20, 2024 at 11:53 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> On Tue, 20 Aug 2024 at 17:46, Robert Haas <robertmhaas@gmail.com> wrote:
> > 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.
>
> Agreed, I'm not really seeing a benefit of returning 4 instead of
> 30004. Both are new numbers that are higher than 3, so on existing
> code they would have the same impact. But any new code would be more
> readable when using version >= 30004 imho.

Yes. And the major * 10000 + minor convention is used in other places
already, for PG versions, so it might already be familiar to some
people. I think if we're going to redefine an existing function, we
might as well just redefine it as you propose -- or perhaps even
redefine it to return major * 10000 + minor always, instead of having
the strange exception for 3.0. I think I'm still on the side of not
redefining it, but if we're going to redefine it, I think we should do
what seems most elegant/logical and just accept that some code may
break.

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