Re: Parsing config files in a directory

On Wed, Oct 28, 2009 at 2:37 AM, Dimitri Fontaine
<dfontaine@hi-media.com> wrote:
> 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.

-- 
greg