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

On Thu, Jul 11, 2019 at 10:11 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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.

Yeah, that seems like a good idea.

> 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.

I had the same thought, but I just realized that's probably
unfriendly: at the point when the client is assembling the list of
names to send to the server, it doesn't know the server version. I
think we're probably best off assuming that any names we don't
recognize are something that got added in a newer server version and
just ignoring them. The client is not powerless to sort this out
after-the-fact: once the connection is made, they'll know the server
version and also have the option to interrogate pg_settings if they
wish.

We also need to think about how to write a test for this patch...

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