Re: changing the endianness of a database

Merlin Moncure wrote:

> Surely it's easier just to have your application dump on schedule and
> add some front end GUI import feature to your app? It looks like you
> are maybe trying to solve the wrong problem...namely that it is too
> difficult for your users to do backup/restore themselves.

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

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.

The ability to build a custom standalone backend that could read (and
only read) a "foreign" database structure would be pretty handy in this
sort of situation and other cases of poorly planned disaster recovery or
migration. Of course, it's much better to avoid such situations, but
where end users are involved they're always going to arise.

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.

--
Craig Ringer