Re: Some 8.4 changes needed according to pg_migrator testing
От | Magnus Hagander |
---|---|
Тема | Re: Some 8.4 changes needed according to pg_migrator testing |
Дата | |
Msg-id | 4A032193.4080203@hagander.net обсуждение исходный текст |
Ответ на | Re: Some 8.4 changes needed according to pg_migrator testing (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Some 8.4 changes needed according to pg_migrator testing
|
Список | pgsql-hackers |
Alvaro Herrera wrote: > Tom Lane wrote: > >> Actually, there's another issue that comes to mind here: since we are >> relying on platform-dependent locale names, including those in the dump >> is going to pose a severe problem for porting dumps across platforms >> (where "different platform" could even mean "different libc release"). >> We're already at risk with respect to dumps from 8.4, even without the >> above-proposed change. >> >> I am not sure what we can do about this. Ideas? > > I don't think there's much we can do apart from telling the user not to > move stuff across platforms that do not have equally named locales. > Maybe what we can do is have a mechanism for pg_restore to map one > locale from the dump file into another. So the user can specify a file > with lines like > "en_US := English_UnitedStates" > etc > > (For text dumps, the only solution would be for the user to edit the > dump manually; perhaps provide a pg_dump switch to avoid dumping > locale config?). We have a pg_dump switch that sets the encoding. Perhaps we could have a pg_dump switch that "fakes" the output locale? Seems awfully kludgy though - I'd much rather see us supporting it on pg_restore and just say that if you are dumping in plaintext, well, use a plaintext editor to edit it. //Magnus
В списке pgsql-hackers по дате отправления: