Re: Proposal: knowing detail of config files via SQL

On Thu, Jan 22, 2015 at 5:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
>> On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

I believe I've run into situations where this would be useful. I
wouldn't be willing to put in the effort to do this myself, but I
wouldn't be prepared to vote against a high-quality patch that someone
else felt motivated to write.

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