Re: Some 8.4 changes needed according to pg_migrator testing - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Some 8.4 changes needed according to pg_migrator testing
Date
Msg-id 4A032193.4080203@hagander.net
Whole thread Raw
In response to Re: Some 8.4 changes needed according to pg_migrator testing  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Some 8.4 changes needed according to pg_migrator testing  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Some 8.4 changes needed according to pg_migrator testing
Next
From: Heikki Linnakangas
Date:
Subject: Outer join bug in CVS HEAD