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. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
