Re: Proposal: knowing detail of config files via SQL

From: David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: knowing detail of config files via SQL
Date: 2015-01-22 22:09:31
Message-ID: CAKFQuwbG=LRS14-mxNLmMOY1ORUqrmiCdMryKFX+e1Kqrp=sug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 22, 2015 at 3:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > Tom Lane-2 wrote
> >> regression=# alter system reset timezone;
> >> ALTER SYSTEM
> >> regression=# select pg_reload_conf();
>
> > How does someone know that performing the above commands will result in
> the
> > TimeZone setting being changed from Asia/Shanghai to US/Eastern?
>
> 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.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-01-22 22:19:24 Re: Proposal: knowing detail of config files via SQL
Previous Message Tom Lane 2015-01-22 22:04:22 Re: Proposal: knowing detail of config files via SQL