Re: (A) native Windows port

From: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: (A) native Windows port
Date: 2002-07-02 15:41:04
Message-ID: 200207021141.04226.lamar.owen@wgcr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Matthew T. O'Connor 2002-07-02 16:04:05 Re: (A) native Windows port
Previous Message Peter Darley 2002-07-02 15:15:01 Bad records in table

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthew T. O'Connor 2002-07-02 16:04:05 Re: (A) native Windows port
Previous Message Bruce Momjian 2002-07-02 15:33:13 Re: listen/notify argument (old topic revisited)