Re: Proposal: knowing detail of config files via SQL

Поиск
Список
Период
Сортировка
От David Fetter
Тема Re: Proposal: knowing detail of config files via SQL
Дата
Msg-id 20150130152424.GA4104@fetter.org
обсуждение исходный текст
Ответ на Re: Proposal: knowing detail of config files via SQL  (Sawada Masahiko <sawada.mshk@gmail.com>)
Ответы Re: Proposal: knowing detail of config files via SQL  (Sawada Masahiko <sawada.mshk@gmail.com>)
Список pgsql-hackers
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?

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: pg_dump with both --serializable-deferrable and -j
Следующее
От: David Fetter
Дата:
Сообщение: Re: Exposing the stats snapshot timestamp to SQL