On Wed, Feb 20, 2008 at 06:38:10PM -0500, Tom Lane wrote:
> Aidan Van Dyk <aidan@highrise.ca> writes:
> > * Josh Berkus <josh@agliodbs.com> [080220 18:00]:
> >> We need a server-based tool for the manipulating postgresql.conf, and
> >> one which is network-accessable, allows updating individual settings,
>
> > Do we need to develop our own set of "remote management" tools/systems,
> > or possibly document some best practices using already available "multi-
> > server managment" tools?
>
> Indeed. If Josh's argument were correct, why isn't every other daemon
> on the planet moving away from textual configuration files?
In my experience, most that *can*, do that. Pretty much every new system
I've installed in the past 5+ years store their entire configuration *in
the database*. The only thing that goes in the config file is the bare
minimum to reach the database.
If they don't have an actual database, it's fairly common to use SQLite or
similar just to get proper database storage for it.
> IIRC, one of the arguments for the config include-file facility was to
> simplify management of multiple servers by letting them share part or
> all of their configuration data. One of the things that bothers me
> considerably about all the proposals made so far in this thread
> (including mine) is that they don't play very nicely with such a
> scenario. Putting a setting into one file that contradicts one made in
> some other file is a recipe for confusion and less admin-friendliness,
> not more.
Which is why we need to keep the old way of doing things *as well*, for
people who want to use that method. But that part only realliy argues
against the option to try to store everything in the database and generate
the file from there (like we do with pg_database etc).
//Magnus