Skip site navigation (1) Skip section navigation (2)

Re: Parsing config files in a directory

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Magnus Hagander <magnus(at)hagander(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parsing config files in a directory
Date: 2009-10-27 21:57:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers


Le 27 oct. 2009 à 18:21, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> a écrit :

> Greg Smith <gsmith(at)gregsmith(dot)com> writes:
>> ... One file per GUC is certainly never going to fly though, it's
>> been hard enough getting people to accept going from one file to  
>> more than
>> one.
> One thing that concerns me a bit about the lack of consensus on that
> is what will happen if different config-adjustment tools adopt  
> different
> philosophies.  If Dimitri writes a tool that drops settings into per- 
> files, and you write one that puts them all in persistent.conf, and
> somebody tries to use both those tools, no good will come of it.

Right, that's why Greg Stark convinced me that we're defining an API  
here, not   just a facility.

> If we forgot about the config-dir idea and just had one file that was
> meant to be hacked by automated tools, the problem would go away.
> However I suspect that that proposal won't fly, so we ought to think
> about providing some guidance to tools writers about what to do.
> Is there any consensus on how multiple config files actually get used
> over in the Apache/etc world?

What they have is different contexts where to apply the same settings.  
You basically write one file per context.

As you are saying that does not translate well to our case where we  
want one context and N tools.

I don't see that opening the possibility to edit the same GUC in more  
than exactly 2 places is giving us anything. First the tool location,  
then the local DBA hand maintained file. Which still could include  
other files, as Kevin does, for park managment purpose.

The DBA friendly option is the existing include directive. includedir  
buys nothing in my mind. We want a tool API and the first tool to  
expose it in the form of SET PERSISTENT. I think :)

In response to

pgsql-hackers by date

Next:From: Scott BaileyDate: 2009-10-27 22:27:57
Subject: Re: xpath_table equivalent
Previous:From: Dimitri FontaineDate: 2009-10-27 21:39:33
Subject: Re: Parsing config files in a directory

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group