Re: initdb.exe changes --locale option - Mailing list pgsql-bugs
From | Dave Page |
---|---|
Subject | Re: initdb.exe changes --locale option |
Date | |
Msg-id | CA+OCxowETQkPTY5PD+JOWpOfm3C_sK3F1uqiTY6REPe5YL7sgg@mail.gmail.com Whole thread Raw |
In response to | Re: initdb.exe changes --locale option (Mike Toews <mwtoews@gmail.com>) |
Responses |
Re: initdb.exe changes --locale option
Re: initdb.exe changes --locale option |
List | pgsql-bugs |
Sandeep, can you look into this and respond on list please? The thread started here: http://archives.postgresql.org/pgsql-bugs/2012-09/msg00083.ph= p It sounds to me like the OS is at fault for not accepting the name it gives to a locale as input, and that the change to the installer would be a workaround rather than a fix - but I haven't had time to dig into it. Thanks. On Wed, Sep 12, 2012 at 4:53 PM, Mike Toews <mwtoews@gmail.com> wrote: > I've found a general solution: with the locale string, replace the > first ", " (comma space) with "_". > > Around line 33 of initcluster.vbs, add: > > strLocale =3D Replace(strLocale,", ","_",1,1) > > I think it is fine to show "English, New Zealand" in the drop-down > menu for the GUI installer, but initcluster.vbs needs to do the > replacement to "English_New Zealand" in order to fulfil the correct > initialisation. > > My testing was conducted using a Python script http://pastebin.com/9epyWz= 7x > which produces a tab delimited table of input locales, and the locale > chosen by initdb.exe, as well as the default language for text search > configuration. > > The results from 200 locales shows some significant problems with > locale detection, such that most "Language, Country" are substituted > with only one country (you will pick up the pattern if you look at the > data). Secondly, there are cases that are completely off: "Tamazight > (Latin), Algeria" : "English_United Kingdom.1252", which is corrected > to "Tamazight (Latin)_Algeria.1252" with the proper substitution. > > However, there are three corner cases (of 200) that either sort-of > breaks things, or doesn't resolve anything: > > Original: Chinese (Traditional), Macao S.A.R. : Chinese (Traditional)_Tai= wan.950 > Replaced: Chinese (Traditional)_Macao S.A.R. : English_United Kingdom.125= 2 > > Original: Lao, Lao P.D.R. : Lao_Lao P.D.R..1252 > Replaced: Lao_Lao P.D.R. : English_United Kingdom.1252 > > Original: Norwegian (Bokm=C3=A5l), Norway : English_United Kingdom.1252 > Replaced: Norwegian (Bokm=C3=A5l)_Norway : English_United Kingdom.1252 > > (Note: I'm testing on a Windows Vista computer from the UK) > > Lastly, I had a look at the source code initdb.c, which appears to > assume only POSIX locale of the format: > [language[_territory][.codeset][@modifier]] > > E.g., see find_matching_ts_config, which assumes this locale format: > http://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dblob;f=3Dsrc/bin= /initdb/initdb.c;h=3D824c7fa7e4c76e0a3b8204ce0cdd21564f23d5df;hb=3DHEAD#l88= 6 > > It should probably handle the WIN32 logic separately from POSIX > locales, but that's a deeper matter. > > -Mike > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs --=20 Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-bugs by date: