Re: Explicit configuration file

Peter Eisentraut wrote:
> 
> 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.

Windows does not supprt symlinks.

> 
> > 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.

This is a bogus argument, you must know that. Do you really beleive this? 

> 
> > 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.

What are you talking about? I am saying that the configuration file should be
able to specify how PostgreSQL works. This has nothing to do with configuring
the OS.

> 
> > 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.

Wrong, named uses named.conf (typically in the /etc directory) to point to
where its files are. And named has the "-c" option to specify which config fle
to use.

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

Sendmail works great, it is dificult to configure, sure, but it does work quite
well. And yes, sendmail has a "-C" option to use a different configuration fle.


> 
> 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.

Again, wrong. Apache is VERY easy to make run multiple instances. As a server,
however, multiple instancs must run on different IP ports. One Apache process
can listen on multple ports, or you can use different configuration files to
specify how this works.

In apache, the option for the configuration file is "-f"

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

Ahh, again, wrong. dhcpd can be started to work on all the ethernet interfaces,
or run one process for each, dhcpd uses the "-cf" option to specify which
configuration file to use. sshd uses the "-f" option to specify which
configuration to use, and more than one instance can be run on different ports.

> 
> 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.

The postgresql.conf file is a great start. It should just be more inclusive of
configuration details. why not be able to specify the configuration file? Why
not be able to specify the hba config file? Why not be able to specify where
the data directory is?

These are things that UNIX admins EXPECT to be in a configuration file, why NOT
put them in?

> 
> > 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.

That's not completely true either. One can take off group all read rights if
they want it to be secret, however, securtity through obscurity is stupid and
foolish.

> 
> > 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.

I find your arguments irrational. Why NOT allow postgres to behave as other
UNIX server applications? If adding a feature neither hurts performance nor
changes the default behavior, but provides more flexability for the admin, why
NOT add it.

Arguing that "Symlinks" are clean is completely rediculous. There are so many
reasons why you DON'T want to use symlinks it is rediculous. Yes symlinks are a
tool in UNIX, one of its great features, but I think I speak for most UNIX
admins, if they can do something without a symlink, they would prefer to do so.

Arguing that PostgreSQL should be limited to one instance per host, putting
everything under one directory is he "cleanest" solution is absurd.

Again, virtually every other server on UNIX has the notion of a configuration
fle outside of its data, why is PostreSQL beter for not having this feature?
Why is being different than other UNIX servers beter? Why is NOT having
configuration options in the configuration file cleaner?