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

On Wed, Aug 21, 2024 at 3:14 PM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)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