From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jacob Burroughs <jburroughs(at)instructure(dot)com>, Dave Cramer <davecramer(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com> |
Subject: | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
Date: | 2024-08-19 20:53:46 |
Message-ID: | CAGECzQRjPHoKViEGNY1ZTFXciscJr9XQjLPbpnwvLdsrZ6-88w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 19 Aug 2024 at 16:16, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> If somebody is using PQprotocolVersion() to detect the arrival of a
> new protocol version, it stands to reason that they only care about
> new major protocol versions, because that's what the function is
> defined to tell you about. Anyone who has done a moderate amount of
> looking into this area will understand that the protocol has a major
> version number and a minor version number and that this function only
> returns the former. Therefore, they should expect that the arrival of
> a new minor protocol version won't change the return value of this
> function.
What I'm trying to say is: I don't think there's any usecase where
people would care about a major bump, but not a minor bump. Especially
keeping in mind that a minor bump had never occurred when originally
creating this function. And because we never did it, there has so far
been no definition of what is the actual difference between a major
and a minor bump.
> I really don't understand why we're still arguing about this. It seems
> to me that we've established that there is some usage of the existing
> function, and that changing the return value will break something.
> Sure, so far as we know that something is "only" regression tests, but
> there's no guarantee that there couldn't be other code that we don't
> know about that breaks worse
My point is that the code that breaks, actually wants to be broken in this case.
> and even there isn't, who wants to break
> regression tests when there's nothing actually wrong?
Updating the regression test would be less work than adding support
for a new API. So if the main problem is
> Now we could
> decide we're going to do it anyway because of whatever reason we might
> have, but it doesn't seem like that's what most people want to do.
>
> I feel like we're finally in a position to get some things done here
> and this doesn't seem like the point to get stuck on. YMMV, of course.
I'd love to hear a response from Jacob and Heikki on my arguments
after their last response. But if after reading those arguments they
still think we should add a new function, I'll update the patchset to
include a new function.
From | Date | Subject | |
---|---|---|---|
Next Message | Kirill Reshke | 2024-08-19 21:14:08 | Re: Incremental View Maintenance, take 2 |
Previous Message | Robert Haas | 2024-08-19 18:20:46 | Re: generic plans and "initial" pruning |