Re: (A) native Windows port

On Tue, 2002-07-09 at 18:05, Hannu Krosing wrote:
> The big change was from 6.x to 7.x where a chunk of data moved from end
> of page to start of page and tableoid column was added. Otherways the
> table structure is quite simple. The difficulties with user _data_ can
> be mainly because of binary format changes for some types and such.
>
> But I still can't see how will having a binary dumper that does mostly
> the work of [ old_backend -c "COPY tablex TO STDOUT" ] help us here.
>
> IIRC the main difficulties in upgrading have always been elsewhere, like
> migrating always changing system table data.

The main problem is getting access to the user data after an upgrade.
There's no particular problem in having to do an initdb, though it is an
inconvenience; the difficulty is simply that any packaged distribution
(rpm, deb, xxx) is going to have to replace all the old binaries. So by
the time the package is ready to do the database upgrade, it has
destroyed the means of dumping the old data. Lamar and I have to jump
through hoops to get round this -- small hoops with flaming rags round
them!

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
expect) that an upgrade will progress without the need for significant
intervention on their part. PostgreSQL makes this really difficult for
the package maintainers, and this has a knock-on effect on the
reliability of the upgrade process and thus on PostgreSQL itself.