Re: Proposal: knowing detail of config files via SQL
От | Sawada Masahiko |
---|---|
Тема | Re: Proposal: knowing detail of config files via SQL |
Дата | |
Msg-id | CAD21AoCpvJrW4dwusd2XO1e1PEX1RNPv1PwZjDY0zd7QRHhyQg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: knowing detail of config files via SQL (David Fetter <david@fetter.org>) |
Ответы |
Re: Proposal: knowing detail of config files via SQL
(Mike Blackwell <mike.blackwell@rrd.com>)
Re: Proposal: knowing detail of config files via SQL (David Fetter <david@fetter.org>) |
Список | pgsql-hackers |
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 Regards, ------- Sawada Masahiko
В списке pgsql-hackers по дате отправления: