Re: initdb.exe changes --locale option

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Mike Toews <mwtoews(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, Sandeep Thakkar <sandeep(dot)thakkar(at)enterprisedb(dot)com>
Subject: Re: initdb.exe changes --locale option
Date: 2012-09-13 20:17:19
Message-ID: CA+OCxowETQkPTY5PD+JOWpOfm3C_sK3F1uqiTY6REPe5YL7sgg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.php

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(at)gmail(dot)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 = 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/9epyWz7x
> 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)_Taiwan.950
> Replaced: Chinese (Traditional)_Macao S.A.R. : English_United Kingdom.1252
>
> 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ål), Norway : English_United Kingdom.1252
> Replaced: Norwegian (Bokmål)_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][(dot)codeset][(at)modifier]]
>
> E.g., see find_matching_ts_config, which assumes this locale format:
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/initdb/initdb.c;h=824c7fa7e4c76e0a3b8204ce0cdd21564f23d5df;hb=HEAD#l886
>
> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2012-09-13 20:37:41 Re: BUG #7516: PL/Perl crash
Previous Message te 2012-09-13 19:17:05 how to proccess record returning null