Re: Proposal: knowing detail of config files via SQL

​This would default to being available to superusers only, right? Details
of the file system shouldn't be available to any random user.​

__________________________________________________________________________________
*Mike Blackwell | Technical Analyst, Distribution Services/Rollout
Management | RR Donnelley*
1750 Wallace Ave | St Charles, IL 60174-3401
Office: 630.313.7818
Mike(dot)Blackwell(at)rrd(dot)com
http://www.rrdonnelley.com

<http://www.rrdonnelley.com/>
* <Mike(dot)Blackwell(at)rrd(dot)com>*

On Fri, Jan 30, 2015 at 9:50 AM, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
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
>
> Regards,
>
> -------
> Sawada Masahiko
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>