Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Date
Msg-id 3235252.1703878585@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
List pgsql-hackers
Jeff Davis <pgsql@j-davis.com> writes:
> On Fri, 2023-12-29 at 13:38 -0500, Tom Lane wrote:
>> This is assuming facts not in evidence.  Why would we want such a
>> thing?

> The problem came up during the binary_formats GUC discussion: it
> doesn't really make sense to change that with a SQL query, and doing so
> can cause strange things to happen.
> We already have the issue with client_encoding and binary format COPY,
> so arguably it's not worth trying to solve it. But protocol-only GUCs
> was one idea that came up.

Yeah, there's definitely an issue about what level of the client-side
software ought to be able to set such parameters.  I'm not sure that
"only the lowest level" is the correct answer though.  As an example,
libpq doesn't especially care what encoding it's dealing with, nor
(AFAIR) whether COPY data is text or binary.  The calling application
probably cares, but then we end up needing a bunch of new plumbing to
pass the settings through.  That's not really providing a lot of
value-add IMO.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Make all Perl warnings fatal
Next
From: Jeff Davis
Date:
Subject: Re: broken master regress tests