On Wednesday 10 July 2002 03:24 am, Jan Wieck wrote:
> Oliver Elphick wrote:
> > The current upgrade process for PostgreSQL is founded on the idea that
> > people build from source. With binary distributions, half the users
> > wouldn't know what to do with source; they expect (and are entitled to
> I have to object here. The PostgreSQL upgrade process is based on
> the idea of dump, install, initdb, restore. That has nothing to
> do with building from source or installing from binaries.
Let me interject a minor point here. I recall upgrade cycles where I had to
install a newer pg_dump in order to get my data out of the old system due to
bugs in the prior pg_dump. Getting two versions of PostgreSQL to cooexist
peacefully in a binary packaged environment is a completely different problem
than the typical 'from source' installation path -- which almost implies two
versions available concurrently. I believe this is the artifact Oliver was
alluding to.
I personally have not had the luxury of having two complete installations
available at one instant during RPM upgrades. Nor will any users of
prepackaged binaries.
> The problem why this conflicts with these package managers is,
> because they work package per package, instead of looking at the
> big picture. Who said you can replace package A before running
> the pre-upgrade script of dependent package B?
How does this create the problem? The postgresql-server subpackages of two
versions are 'Package A' above. There is no package B.
Define 'the big picture' for all possible permutations of installed packages,
please.
> Somehow this looks
> like a foreign key violation to me. Oh, I forgot, RI constraints
> are for documentation purposes only ... Greetings from the MySQL
> documentation ;-)
Is sarcasm really necessary?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11