Re: Explicit configuration file

mlw writes:

> > That could be mildly useful, although symlinks make this already possible,
> > and a bit clearer, IMHO.
>
> On systems which support symlinks, yes.

All systems that are able to run PostgreSQL support symlinks.

Really.

> Also, a system should be "self documenting" i.e. one should be able to put
> clues to why certain things were done. Symlinks allow one to do something, yes,
> but if I leave the company, someone besides me should be able to administrate
> the system I leave behind.
>
> Don't you consider symlinks as a kind of a hack around a basic flaw in the
> configuration process?

Elsewhere you stated that a certain aspect of the current situation is not
very Unix-like. Well, symlinks are very Unix-like. They have been
invented exactly for the purpose of sharing files for several purposes,
while maintaining the identity of the "original" (else use hard links).
They are not hacks, they can be nested and used recursively, they are
self-documenting and they don't prevent you from adding your own
documentation either. I don't want to be adding a new feature anytime
someone doesn't like the tools the operating system already provides.

> Shouldn't the configuration file let you completely specify how your
> system is configured?

Sure, it specifies how the PostgreSQL server behaves. It is not concerned
with telling your operating system how to behave.

> Think about named, sendmail, apache, dhcpd, sshd, etc. All these programs have
> the notion that he configuration is separate from the working data. To see how
> they are configured, you just go to the "/etc" or "/etc/pgsql" directory and
> read the configuration file(s).

named: Configuration and data files are both under /var/named.

sendmail: is not a suitable example for a well-designed, easy-to-use
software system.

apache: Does not easily allow running multiple instances on one host.
The virtual host setups I've seen put both configuration and data files
under the same per-host directory. Imagine what a mess it would be
otherwise.

dhcpd, sshd: Only one instance per host supported/necessary.

Ironically, if sendmail hadn't the bear it is, my former employer would
never have switched to a certain alternative MTA and I would never have
gotten the inspiration for creating the postgresql.conf file the way it is
today.

> With postgres, you need to know where, and go to the data directory, as ROOT
> (or the pg user) because you can't enter it otherwise, look at postgresql.conf,

Other users don't have a business reading that file. That's a feature.

> do an "ls -l" to see which parts are symlinked and which are not. If you have
> multiple PostgreSQL installations, you have to go to each directory and repeat
> the process. (hyperbole, I know)

The alternative is that you have to scan the startup code for each server
(where would that be?) and check whether it has the -C option or not or
whether it has been overridden somewhere to see which configuration it
will end up using.

All of this wouldn't be a problem if we only allowed at most one server
per host. Then we could standardize on fixed locations for everything.
But we do allow and many people do use more than one server instance per
host, and there it can be a great mess finding out where everything
belongs. Putting everything under one directory by default is undoubtedly
the cleanest solution. If you want to spread things around, use the tools
that the system gives you.

--
Peter Eisentraut peter_e(at)gmx(dot)net