Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
От | Tom Lane |
---|---|
Тема | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
Дата | |
Msg-id | 3235252.1703878585@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
|
Список | 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 по дате отправления: