Re: Some 8.4 changes needed according to pg_migrator testing
От | Tom Lane |
---|---|
Тема | Re: Some 8.4 changes needed according to pg_migrator testing |
Дата | |
Msg-id | 24076.1241724721@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Some 8.4 changes needed according to pg_migrator testing (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Some 8.4 changes needed according to pg_migrator
testing
Re: Some 8.4 changes needed according to pg_migrator testing |
Список | pgsql-hackers |
Magnus Hagander <magnus@hagander.net> writes: > Alvaro Herrera wrote: >> (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. I don't think a solution that requires you to know about this in advance (ie when you make the dump) is going to be very satisfactory. I'm inclined to think that the most usable answer is to have some way of getting CREATE DATABASE itself to apply a locale-name mapping. Or we could try to make the user-visible locale names platform-independent in the first place, a la David's not-silly-at-all suggestion. I think the part that goes "en_US" or whatever is actually quite well standardized (except for good ol' Windows, but we could provide a mapping from the Unix-style names to Windows names). It's the encoding-name part that's not very stable. If we could hide that from the user and tack it on internally, things would be much better. regards, tom lane
В списке pgsql-hackers по дате отправления: