Re: Some 8.4 changes needed according to pg_migrator testing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Some 8.4 changes needed according to pg_migrator testing
Date: 2009-05-07 19:32:01
Message-ID: 24076.1241724721@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-05-07 19:36:37 Re: Serializable Isolation without blocking
Previous Message Tom Lane 2009-05-07 19:23:48 Re: Outer join bug in CVS HEAD