Re: Explicit config patch 7.2B4

Vince Vielhaber <vev@michvhf.com> writes:

> On 19 Dec 2001, Andrew G. Hammond wrote:
> 
> > ObFlame: BSD sux.  That little devil looks kinda fruity to me, and I'll
> > bet Tux could whup his ass.
> 
> I was going to respond until I saw this.  I don't waste my time with
> children.
> 
> Vince.

What, you didn't see the ObFlame: disclosure.  It seemed like a fairly
obvious joke to me.

I agree with Andrew.  One of the things that I like about Debian is
that all of the config files for every package that is installed via
the Debian packaging system is somewhere in /etc.  Yes, this makes it
difficult (sometimes) to translate the documentation for packages that
expect to have that information somewhere else, but it is very useful
for those cases (like PostgreSQL for example) that put the
configuration files somewhere totally strange (the application's data
directory is not where Unix admins start looking for config files).

The long and the short of it is that pretty much every Unix has a
preference for where the configuration files, data files, log files,
etc, should go, and the various users probably aren't ever going to
simply agree that one way is better than the rest.  After all, if
there is one common trait among Unix admins it is the belief in a "one
true way."  Unfortunately, that "one true way" seems to vary radically
depending on which Unix admin you talk to.  I might agree with Debian
that configuration files belong in /etc, you might feel that they
belong somewhere else.  Currently, however, it doesn't matter what we
want.  The configuration files end up in the PostgreSQL data directory
whether we like it or not.  We can use symlinks to pretend that these
files are somewhere else, but we can't really move them.

Being able to configure the placement of these files would be a huge
win.  We can always default to leaving the files right where they
currently are, but making this configurable would help those people
who package PostgreSQL for one organization or another tremendously.
And since most of PostgreSQL's users end up using the version supplied
by their vendor (whether it's a FreeBSD port or a RedHat RPM or
whatever) it clearly is a win to give these packagers the flexibility
they need.

Not that any of you should listen to me, as I am just some random
PostgreSQL user who happens to be subscribed to HACKERS because I
wanted to see what the real scoop on 7.2 was :).

Jason