On Sunday 16 February 2003 00:16, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


Reply via email to