Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)
От | Andres Freund |
---|---|
Тема | Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status) |
Дата | |
Msg-id | 20191011214949.hbw5soqmj7shtnu2@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)
|
Список | pgsql-hackers |
Hi, On 2019-10-11 16:30:17 -0400, Robert Haas wrote: > On Fri, Oct 11, 2019 at 8:21 AM Dave Cramer <pg@fastcrypt.com> wrote: > > So off the top of my head providing a system function seems like the way to go here unless you were contemplating addingsomething to the protocol ? > > Since the list of reportable GUCs is for the benefit of the driver, > I'm not sure why this would need to be changed after the connection > has been established. Because of connection pooling. Consider the pooler inbetween the client and the server. The pooler can't report back settings changes it doesn't get itself. And just asking for all settings upfront seems problematic. > But, if it does need to be changed, it seems like a terrible idea to > allow it to be done via SQL. Otherwise, the user can break the driver > by using SQL to set the list to something that the driver's not > expecting, and there's nothing the driver can do to prevent it. Uhm. The driver can just ignore GUCs it's not interested in, like our docs have told them for a long time? And I mean if somebody is able to issue sql, then they likely have some control over the driver as well. I don't understand the problem here. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: