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: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Jelte Fennema-Nio <postgres@jeltef.nl>, 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-23T14:02:26Z
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 Wed, Aug 21, 2024 at 3:14 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> Put another way: we've seen that our protocol-version joint has rusted
> [1, 2]. I agree that needs to be fixed. But I also believe that we
> shouldn't try to smash the joint open with a hammer, and that belief
> seems philosophically at odds with the approach being taken upthread.

+1. We are inevitably going to break some things, especially if we
introduce changes that affect everyone, such as longer cancel keys,
rather than just optional features. But we owe it not only to our
rather large user base but also to ourselves to minimize the extent of
the breakage as much as possible. I have yet to experience the
situation where I commit something that angers users and my life
nevertheless improves afterward.

Personally, I'm 100% convinced at this point that we're arguing about
the wrong problem. Before, I didn't know for sure whether anyone would
be mad if we redefined PQprotocolVersion(), but now I know that there
is at least one person who will be, and that's Jacob. If there's one
among regular -hackers posters, there are probably more. Since Jelte
doesn't seem to want to produce the patch to add
PQminorProtocolVersion(), I suggest that somebody else does that --
Jacob, do you want to? -- and we commit that and move on.

Then we can get down to the business of actually changing some stuff
at the protocol level. IMHO, that's what should be scary and/or
controversial here, and it's also imperative that if we're going to do
it, we do it soon. If we make the mistake of dumping a bunch of
changes that break half of the ecosystem into the tree just before
feature freeze, there's no time for us to fix anything more than
trivial problems. If more serious problems turn up, it's a revert. If
we start to get some of these changes made now, there's a lot more
room for error. Let's take advantage of the time available while we
still have it.

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