Re: (A) native Windows port

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