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(at)fetter(dot)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(at)gmail(dot)com> wrote:
> >> > 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.
> >> >
> >>
> >> 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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

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