Re: (A) native Windows port - Mailing list pgsql-hackers

From Lamar Owen
Subject Re: (A) native Windows port
Date
Msg-id 200207021141.04226.lamar.owen@wgcr.org
Whole thread Raw
In response to Re: (A) native Windows port  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
On Tuesday 02 July 2002 09:52 am, Jan Wieck wrote:
> Christopher Kings-Lynne wrote:
> > > > It would all work out of the box and would do wonderful things for
> > > > the Postgres community.

> > > I like this idea, but let me just bring one little issue to note: are
> > > you going to handle upgrades, and if so, how?  How are you going to do
> > > a major
> > > version upgrade?

> > Well, the easiest way would be to get them to uninstall the old version
> > first, but I'm sure it can be worked out.  Perhaps even we shouldn't
> > overwrite the old version anyway?

> The question is not how to replace some .EXE and .DLL files or modify
> something in the registry. The question is what to do with the existing
> databases in the case of a catalog version change. You have to dump and
> restore.

Now, riddle me this: we're going to explain the vagaries of 
dump/initdb/restore to a typical Windows user, and further explain why the 
dump won't necessarily restore because of a bug in the older version's 
dump....

The typical Windows user is going to barf when confronted with our extant 
'upgrade' process.  While I really could not care less if PostgreSQL goes to 
Windows or not, I am of a mind to support the Win32 effort if it gets an 
upgrade path done so that everyone can upgrade sanely.  At least the Windows 
installer can check for existing database structures and ask what to do -- 
the RPM install cannot do this.  In fact, the Windows installer *must* check 
for an existing database installation, or we're going to get fried by typical 
Windows users.

And if having a working, usable, Win32 native port gets the subject of good 
upgrading higher up the priority list, BY ALL MEANS LET'S SUPPORT WIN32 
NATIVELY! :-) (and I despise Win32....)

But it shouldn't be an installer issue -- this is an issue which cause pain 
for all of our users, not just Windows or RPM (or Debian) users.  Upgrading 
(pg_upgrade is a start -- but it's not going to work as written on Windows) 
needs to be core functionality.  If I can't easily upgrade my database, what 
good are new features going to do for me?

Martin O has come up with a 'pg_fsck' utility that, IMHO, holds a great deal 
of promise for seamless binary 'in place' upgrading.  He has been able to 
write code to read multiple versions' database structures -- proving that it 
CAN be done.

Windows programs such as Lotus Organizer, Microsoft Access, Lotus Approach, 
and others, allow you to convert the old to the new as part of initial 
startup.  This will be a prerequisite for wide acceptance in the Windows 
world, methinks.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: listen/notify argument (old topic revisited)
Next
From: "Matthew T. O'Connor"
Date:
Subject: Re: (A) native Windows port