Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status) - Mailing list pgsql-hackers

From Dave Cramer
Subject Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)
Date
Msg-id CADK3HHLPXK6m9_qt5s7cTSYC8CLnx0_dJFFa3E239KQTi87ZEA@mail.gmail.com
Whole thread Raw
In response to Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)
List pgsql-hackers


On Sat, 12 Oct 2019 at 05:05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andres Freund <andres@anarazel.de> writes:
> On 2019-10-11 16:30:17 -0400, Robert Haas wrote:
>> 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?

Certainly it should do that; but the problematic case is where it
*doesn't* get told about something it's depending on knowing about.

                        regards, tom lane


Here's an updated patch that addresses some of Andres' concerns specifically does not use strtok.

As far as addressing connection poolers goes; one thought is to use the cancellation key to "validate" the SQL. 
This should be known to all drivers and pool implementations. Thoughts ?

Dave
Attachment

pgsql-hackers by date:

Previous
From: btendouan
Date:
Subject: Re: pgbench - extend initialization phase control
Next
From: Dilip Kumar
Date:
Subject: Re: Questions/Observations related to Gist vacuum