On Wed, Oct 28, 2009 at 2:37 AM, Dimitri Fontaine <dfonta...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
