Re: changing the endianness of a database

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: changing the endianness of a database
Дата
Msg-id 4828ABC4.3070908@postnewspapers.com.au
обсуждение исходный текст
Ответ на Re: changing the endianness of a database  ("Merlin Moncure" <mmoncure@gmail.com>)
Ответы Re: changing the endianness of a database
Список 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 по дате отправления:

Предыдущее
От: "Vic Simkus"
Дата:
Сообщение: Recovering database after disk crash
Следующее
От: Justin
Дата:
Сообщение: Re: rounding problems