Re: changing the endianness of a database

> Maybe it's an opportunity to introduce the users to backups.

Yes, we do backups for the user, but the problem with Apple's migration is
that it happens not on a schedule that meshes with the backup schedule. Our
applications have fairly frequently changing data.

> Honestly, though, PostgreSQL doesn't seem to be designed for application
> bundling and embedding, where the user never knows there's a database
> engine present. I'm under the impression that there's no consideration
> of what happens if you move from 32 to 64 bit hosts, big endian to
> little endian, etc; it's expected that you'll dump and reload.

Agreed that PGSQL isn't designed for embedding, but it's actually very close
to being supportable in that kind of use model. The binaries and database
files are nicely contained, the server/libraries can be easily built as a
Universal (i.e. multi-architecture) binary for Macs, and the server is
actually quite small (26MB for a complete install as PPC/Intel binaries not
stripped) compared to commercial databases.

If the data files themselves were portable or convertible, then it would be
an almost perfect solution.

> It's a pity the system cloning/migration tools don't have hooks for
> applications to do pre-migration and post-migration tasks, so you could
> just dump then initdb and reload.

Yes, that's exactly the problem. For the migration, you actually shut down
the old Mac that's the source of the data and boot it in a special FireWire
disk mode, and connect it like a hard disk to the new Mac. As a result,
there's no code able to run on the source computer during the migration.

For our kind of users (non-technical often), it's almost impossible to have
them plan out stuff or even consider what needs to be done in terms of
advance tasks.

I had hoped that there would be a way to "rescue" the database, even if it
took a lot of processing...

Chris

--
Chris Saldanha
Parliant Corporation
http://www.parliant.com/