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 Tom Lane
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 23104.1562854293@sss.pgh.pa.us
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>)
Responses 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
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.

Therefore, at least for qualified GUC names, we can't issue an error
for unrecognized names.  But maybe it should complain about unrecognized
unqualified names.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Dave Cramer
Date:
Subject: Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)
Next
From: Robert Haas
Date:
Subject: Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)