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 Robert Haas
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 CA+TgmoahzNkYaMJ8hdRfLHJ-7R3-q4Bhf1MWLYhJ3w3cCF+wYg@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)  (Dave Cramer <pg@fastcrypt.com>)
Responses Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)  (Chapman Flack <chap@anastigmatix.net>)
Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Mark Wong
Date:
Subject: Re: stress test for parallel workers
Next
From: Andres Freund
Date:
Subject: Re: stress test for parallel workers