| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Jelte Fennema-Nio <me(at)jeltef(dot)nl>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dave Cramer <davecramer(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jacob Burroughs <jburroughs(at)instructure(dot)com>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Pavel Stehule <pavel(dot)stehule(at)gmail(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: | 2023-12-29 19:36:25 |
| Message-ID: | 3235252.1703878585@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2023-12-29 20:10:26 | Re: broken master regress tests |
| Previous Message | Peter Eisentraut | 2023-12-29 19:27:31 | Re: Make all Perl warnings fatal |