David Johnston <david.g.johnston@gmail.com> writes:
> On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Is that a requirement, and if so why? Because this proposal doesn't
>> guarantee any such knowledge AFAICS.
> The proposal provides for SQL access to all possible sources of variable
> value setting and, ideally, a means of ordering them in priority order, so
> that a search for TimeZone would return two records, one for
> postgresql.auto.conf and one for postgresql.conf - which are numbered 1 and
> 2 respectively - so that in looking at that result if the
> postgresql.auto.conf entry were to be removed the user would know that what
> the value is in postgresql.conf that would become active. Furthermore, if
> postgresql.conf has a setting AND there is a mapping in an #included file
> that information would be accessible via SQL as well.
I know what the proposal is. What I am questioning is the use-case that
justifies having us build and support all this extra mechanism. How often
does anyone need to know what the "next down" variable value would be?
And if they do need to know whether a variable is set in postgresql.conf,
how often wouldn't they just resort to "grep" instead? (Among other
points, grep would succeed at noticing commented-out entries, which this
mechanism would not.)
GUC has existed in more or less its current state for about 15 years,
and I don't recall a lot of complaints that would be solved by this.
Furthermore, given that ALTER SYSTEM was sold to us as more or less
obsoleting manual editing of postgresql.conf, I rather doubt that it's
changed the basis of discussion all that much.
regards, tom lane