Re: initdb.exe changes --locale option

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/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)_Taiwa=
n.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=E5l), Norway : English_United Kingdom.1252
Replaced: Norwegian (Bokm=E5l)_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/i=
nitdb/initdb.c;h=3D824c7fa7e4c76e0a3b8204ce0cdd21564f23d5df;hb=3DHEAD#l886

It should probably handle the WIN32 logic separately from POSIX
locales, but that's a deeper matter.

-Mike