On Wed, Oct 28, 2009 at 2:37 AM, Dimitri Fontaine
> That's why I'm proposing the following API at file level:
That's exactly the same as putting them all in the same file, only a
different syntax. It still requires that any program understand what
every other program was trying to do.
>> It's much simpler and more reliable to have each program generate a
>> separate file.
> On the viewpoint of the program itself only. For the DBA, that soon
> becomes a nightmare because the same GUC could come from any number of
> tools and the precedence rules, even explicit and as easy as
> alphanumeric orderding (which locale already?), make it error prone.
But the DBA *wants* to control those precedence rules. The automatic
software certainly can't unless they know what other automatic
software exists in the world -- or will exist in the future.
> I really want to insist on having only ONE location for settings from
> tools (all of them) and one location for manual/local editing.
>> time it's generated. It doesn't have to worry about anything else
>> parsing or making sense of the file except the database server itself.
> But it'll never know if the settings it just generated are superseded by
> some other tool's configuration file.
That's precisely what makes things simpler. The less each module has
to know about each other module the simpler and more reliable it will
be. I actually would suggest that they check the current "source" by
checking with postgres, just to give a warning.
In response to
pgsql-hackers by date
|Next:||From: Josh Berkus||Date: 2009-10-28 16:50:09|
|Subject: Re: Where's the docs?|
|Previous:||From: Greg Stark||Date: 2009-10-28 16:39:34|
|Subject: Re: Parsing config files in a directory|