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