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 CADK3HHJVh+JkVzdpu301OytD1-5haR=CSaQrPHdSRsuERXn2jA@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)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers


On Thu, 11 Jul 2019 at 10:19, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Jul 11, 2019 at 10:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > 3. I'm not sure that just ignoring any GUCs we don't find is the right
> > thing.  I'm also not sure that it's the wrong thing, but it might be.
> > My question is: what if there's an extension-owned GUC in play? The
> > library probably isn't even loaded at this stage, unless it's in
> > shared_preload_libraries.
>
> Gut reaction is that define_custom_variable would need to consult
> the list to see if a newly-defined variable should be marked GUC_REPORT.

This suggests creating a list in guc.c instead. I'm unclear as to the visibility of variables in there
How do I make this list visible only to the session ?




pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pgbench - add option to show actual builtin script code
Next
From: Alexander Korotkov
Date:
Subject: Re: Add missing operator <->(box, point)