Re: location of the configuration files

On Sunday 16 February 2003 00:16, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Would you mind elucidating which point of view is yours?

> Primarily, one that wants to have multiple postmasters running, of the
> same or different versions; including test and temporary installations
> that mustn't conflict with the existing primary installation on a machine.

Well, due to our upgrading difficulty, having multiple versions running has
its advantages.

> You're talking about making manual installations significantly more
> difficult (and error-prone, I think) in order to simplify automated
> installs.  Now you've acknowledged that your script can do what
> you want it to, and in fact already does.  Why is it good to make my
> life more difficult to make a script's easier?  Cycles are cheap.
> I like to think that my time is worth something.

The script's been out there for awhile.  It does some things well, and some
things not so well.  The config files are still coresident with the database,
and backup is more difficult than it can be.  Meeting all these needs (with
configure switches, configuration file directives, etc) would be a good
thing.  And that's what I'm after; maximum usability for the maximum
audience.  I believe pretty strongly that the usage to which you or I would
put PostgreSQL is probably quite different from the average user's way of
using PostgreSQL.  Most probably the typical user has a single installation
with multiple databases with little need to run isolated postmasters.

> Nor will I buy an argument that only a few developers have need for test
> installations.  Ordinary users will want to do that anytime they are
> doing preliminary tests on a new PG version before migrating their
> production database to it.  To the extent that you make manual selection
> of a nonstandard datadir location more difficult and error-prone, you
> are hurting them too.

While I'm not going to speak for all users, I know that I don't put a
development database system on my production servers.  The production machine
only runs production servers, period.  Hardware is cheap.  I have development
machines for development databases.  One also has the error-prone PATH issues
with multiple versions, which, if you are running a typical RPM installation
becomes quite difficult to manage, since the RPM version's executables are in
/usr/bin.  This could be changed; I've thought about changing it.  But I'm
not sure of the best way to make multiple versions peacefully and seamlessly
coexist -- particularly when older versions may not even build on the newer
OS: but we've been over that discussion.

Care for a poll?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11