Re: changing the endianness of a database
От | Shane Ambler |
---|---|
Тема | Re: changing the endianness of a database |
Дата | |
Msg-id | 4828D467.9050202@Sheeky.Biz обсуждение исходный текст |
Ответ на | Re: changing the endianness of a database ("A.M." <agentm@themactionfaction.com>) |
Список | pgsql-general |
A.M. wrote: > You know that you don't have to compile postgresql as "Universal", > right? If you have separate PPC and Intel versions (not lipo'd > together), then, presumably, you should be able to figure out which one > needs to run. The PPC postgresql would then run on the Macintel under > Rosetta and you would then have control to proceed with an automatic > dump/restore. However, this would not work for someone moving the > database from an Intel machine to a PPC machine. That would be my suggestion - run a ppc version to dump then restore with an intel version. Maybe a startup script can detect when to do this. Maybe this is an argument against making universal postgres binaries. > Postgresql is simply not well-suited for such uncontrolled environments. > What happens when you upgrade postgresql? Do you then ship with 4 > version of the db (Intel/PPC * 8.2/83)? Perhaps you should dump all the > non-transient data whenever the application is shut down (in > anticipation of an upgrade)? As far as upgrades that could/should be handled in the installer script. Dump from the installed version then install the new one and restore. That is - using Apple's installer setup. -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz
В списке pgsql-general по дате отправления: