Re: changing the endianness of a database - Mailing list pgsql-general

From Craig Ringer
Subject Re: changing the endianness of a database
Date
Msg-id 4828ABC4.3070908@postnewspapers.com.au
Whole thread Raw
In response to Re: changing the endianness of a database  ("Merlin Moncure" <mmoncure@gmail.com>)
Responses Re: changing the endianness of a database  ("Chris Saldanha" <postgres@cfs.parliant.com>)
List pgsql-general
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

pgsql-general by date:

Previous
From: "Vic Simkus"
Date:
Subject: Recovering database after disk crash
Next
From: Justin
Date:
Subject: Re: rounding problems