On 02/05/2008 11:38 AM, Tom Lane wrote:
> Clemens Schwaighofer <cs@tequila.co.jp> writes:
>> * Disallow database encodings that are inconsistent with the server's
>> locale setting (Tom)
>
>> does this mean, if my server LOCALE is for example UTF-8.en_US, and I want
>> to create a EUC_JP database it gets rejected? do I missunderstand that?
>
> Nope, you have it correctly.
okay, good, as I finally have a reason to change this then on those view
databases.
>> Normaly my servers have default locale set to UTF-8.en_US but also have the
>> locales for UTF-8.ja_JP and EUC_JP there, 99.9% of my databases are utf-8,
>> but I have some clients that created EUC_JP databases, will the upgrade
>> affect this?
>
> I'm surprised your clients haven't been screaming about bogus sorting
> and upper/lowercasing behavior.
well, originally they were on a server that is also in EUC_JP, but they
need to move away to one of my servers that is pure UTF-8, and I cannot
change this setting because of my other databases, so probably better to
convert them over to UTF-8 and adept the scripts to convert to the
target encoding, rather than going on with the same mess.
> If you want to support multiple encodings, the only safe locale choice
> is (and always has been) C. If you doubt this, troll the archives for
> awhile --- for example, searching for locale+encoding in pgsql-bugs
> should provide plenty of amusing reading matter. 8.3 is just refusing
> to do things that are known to be unsafe in previous releases.
>
> regards, tom lane
--
[ Clemens Schwaighofer -----=====:::::~ ]
[ IT Engineer/Manager, TEQUILA\ Japan IT Group ]
[ 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN ]
[ Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jp ]
