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

On Tue, 20 Aug 2024 at 23:48, Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
> That guarantee (if adopted) would also make it possible for my use
> case to proceed correctly, since a libpq client can still speak 3.0
> packets on the socket safely.

Not necessarily (at least not how I defined it). If a protocol
parameter has been configured (possibly done by default by libpq),
then that might not be the case anymore. So, you'd also need to
compare the current values of the protocol parameters to their
expected value.

> But in that case, PQprotocolVersion
> should keep returning 3, because there's an explicit reason to care
> about the major version by itself.

I agree that there's a reason to care about the major version then,
but it might still be better to fail hard for people that care about
protocol details. Because when writing the code that checked
PQprotocolVersion there was no definition at all of what could change
during a minor version bump. So there was no possibility to reason for
that person if they should be notified of a minor version bump or not.
So notifying the author of the code by failing the check would be
erring on the safe side, because maybe they would need to update their
code that depends on the protocol details. If not, and they then
realize that our guarantee is strong enough for their use case, then
they could replace their check with something like:

PQprotocolVersion() >= 3 && PQprotocolVersion() < 40000

To be clear, the argument for changing PQprotocolVersion() is
definitely less strong if we'd provide such a guarantee. But I don't
think the problem is completely gone either.