Re: Parsing config files in a directory

--
dim

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-
> GUC
> 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 :)
>