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

From: Jelte Fennema-Nio <me(at)jeltef(dot)nl>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jacob Burroughs <jburroughs(at)instructure(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dave Cramer <davecramer(at)gmail(dot)com>, "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>
Subject: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Date: 2024-01-05 17:31:56
Message-ID: CAGECzQSq9g5W5oK_XZTSi161uSDs8C-1bznOxO0+4Szq35zW6w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 5 Jan 2024 at 17:28, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> First, I don't see a reason to bump the protocol version. The whole
> reason for adding support for protocol options (_pq_.whatever) is so
> that we wouldn't have to change the protocol version to add new
> message types. At some point we may want to make a change that's large
> enough that we have to do that, or a large enough number of small
> changes that it seems worthwhile, but as long as we can add new
> features without bumping the protocol version, it seems advantageous
> to avoid doing so. It seems easier to reason about and less likely to
> break older clients.

While I agree that it's not strictly necessary, I also feel that you
think the a minor protocol version bump a much bigger deal than it is
(afaict). The protocol is designed in such a way that bumping the
minor version can be done without any problems. There is no
possibility of breaking older clients, because the server will
silently downgrade to the version that the client asks for.

I would be okay not doing the actual bump, but I think at least having
the infrastructure in libpq to support a future bump would be quite
useful (i.e. patch 0002 and 0003).

> > - How do you get the value of a protocol parameter status? Do we
> > expect the client to keep track of what it has sent? Do we always send
> > a ParameterStatus message whenever it is changed? Or should we add a
> > ParamaterGet protocol message too?
>
> I would expect that the client would have full control over these
> values and so the configured value would always be the default (which
> should be non-configurable to avoid ambiguity) unless the client set
> it to something else (in which case the client should know the value).
> So I would think that we'd only need a message to set parameter
> values, not one to get them.

Based on my short experience writing these patches, even for
testing/debugging it's quite useful to be able to do SHOW
_pq_.some_protocol_parameter

I think that's a major benefit of re-using the GUC system.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-01-05 17:35:35 Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Previous Message Robert Haas 2024-01-05 17:26:18 Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs