On 02/05/2008 11:38 AM, Tom Lane wrote: > Clemens Schwaighofer <cs@xxxxxxxxxxxxx> 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 ] ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
