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 24080.1562855750@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:
> 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...

All of the above is based on the assumption that this isn't a plain
old USERSET GUC, which I'm not really seeing the argument for.
OK, there might be *implementation* reasons why we would rather not
deal with on-the-fly changes to the list, but there's no advantage
to users in it.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: pg_stat_database update stats_reset only by pg_stat_reset
Next
From: Tom Lane
Date:
Subject: Re: base backup client as auxiliary backend process