Re: Proposal: knowing detail of config files via SQL

On Sat, Jan 31, 2015 at 12:50:20AM +0900, Sawada Masahiko wrote:
> On Sat, Jan 31, 2015 at 12:24 AM, David Fetter <david@fetter.org> wrote:
> > On Fri, Jan 30, 2015 at 09:38:10PM +0900, Sawada Masahiko wrote:
> >> On Tue, Jan 27, 2015 at 3:34 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> >> > On Thu, Jan 22, 2015 at 5:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> >> 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?
> >> >
> >> > 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.
> >> >
> >>
> >> Attached patch adds new view pg_file_settings (WIP version).
> >> This view behaves like followings,
> >> [postgres][5432](1)=# select * from pg_file_settings ;
> >>             name            |      setting       |
> >>   sourcefile
> >> ----------------------------+--------------------+--------------------------------------------------------
> >>  max_connections            | 100                |
> >> /home/masahiko/pgsql/master/3data/postgresql.conf
> >>  shared_buffers             | 128MB              |
> >> /home/masahiko/pgsql/master/3data/postgresql.conf
> >
> > This looks great!
> >
> > Is there a reason not to have the sourcefile as a column in
> > pg_settings?
> >
> 
> pg_file_settings view also has source file column same as pg_settings.
> It might was hard to confirm that column in previous mail.
> I put example of pg_file_settings again as follows.
> 
> [postgres][5432](1)=# select * from pg_file_settings where name = 'work_mem';
> -[ RECORD 1 ]------------------------------------------------------
> name       | work_mem
> setting    | 128MB
> sourcefile | /home/masahiko/pgsql/master/3data/hoge.conf
> -[ RECORD 2 ]------------------------------------------------------
> name       | work_mem
> setting    | 64MB
> sourcefile | /home/masahiko/pgsql/master/3data/postgresql.auto.conf

Masuhiko-san,

I apologize for not communicating clearly.  My alternative proposal is
to add a NULL-able sourcefile column to pg_settings.  This is as an
alternative to creating a new pg_file_settings view.

Why might the contents of pg_settings be different from what would be
in pg_file_settings, apart from the existence of this column?

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate