Thread: initdb.exe changes --locale option
I'm using the "postgresql-9.2.0-1-windows.exe" installer, from Enterprise DB, on a Windows Vista 32-bit computer. The issue was noticed with the GUI installer, where I chose the local option "English, New Zealand" from a drop-down menu, but the resulting database cluster has "English_United States.1252". With initdb.exe, I see that --locale has unexpected behaviour. I'll present a few examples that each represent key : value, where key is set with --local="key" and value is from the output: The database cluster will be initialized with locale "value". C : C English : English_United States.1252 French : French_France.1252 nonsense : English_United Kingdom.1252 French, Canada : French_France.1252 French_Canada : French_Canada.1252 English, Canada : English_United States.1252 English_New_Zealand : English_United Kingdom.1252 English, New Zealand : English_United States.1252 English_New Zealand : English_New Zealand.1252 There are some interesting interpretations in the above, but I understand they probably depend on the OS (Windows Vista, in this case). In the install-postgresql.log file I see attempts to get a list of available system locales: Executing C:\Users\mwtoews\AppData\Local\Temp\postgresql_installer\getlocales.exe Script exit code: 0 Script output: AfrikaansxxCOMMAxxxxSPxxSouthxxSPxxAfrica=Afrikaans, South Africa AlbanianxxCOMMAxxxxSPxxAlbania=Albanian, Albania ... EnglishxxCOMMAxxxxSPxxCanada=English, Canada ... EnglishxxCOMMAxxxxSPxxNewxxSPxxZealand=English, New Zealand ... EnglishxxCOMMAxxxxSPxxUnitedxxSPxxKingdom=English, United Kingdom EnglishxxCOMMAxxxxSPxxUnitedxxSPxxStates=English, United States ... FrenchxxCOMMAxxxxSPxxCanada=French, Canada FrenchxxCOMMAxxxxSPxxFrance=French, France where it appears that the value after "=" is used to populate the drop-down menu. -Mike
Furthermore, to compare with initdb.exe from 9.1 on the same computer, here are the key : value pairs from the --locale="key" and locale used. >"C:\Program Files\PostgreSQL\9.1\bin\initdb.exe" --version initdb (PostgreSQL) 9.1.4 C : C English : English French : French nonsense : English_United Kingdom.1252 French, Canada : French, Canada French_Canada : French_Canada English, Canada : English, Canada English_New_Zealand : English_United Kingdom.1252 English, New Zealand : English, New Zealand English_New Zealand : English_New Zealand
Hi On Mon, Sep 10, 2012 at 10:07 PM, Mike Toews <mwtoews@gmail.com> wrote: > I'm using the "postgresql-9.2.0-1-windows.exe" installer, from > Enterprise DB, on a Windows Vista 32-bit computer. > > The issue was noticed with the GUI installer, where I chose the local > option "English, New Zealand" from a drop-down menu, but the resulting > database cluster has "English_United States.1252". > > With initdb.exe, I see that --locale has unexpected behaviour. I'll > present a few examples that each represent key : value, where key is > set with --local="key" and value is from the output: The database > cluster will be initialized with locale "value". > > C : C > English : English_United States.1252 > French : French_France.1252 > nonsense : English_United Kingdom.1252 > French, Canada : French_France.1252 > French_Canada : French_Canada.1252 > English, Canada : English_United States.1252 > English_New_Zealand : English_United Kingdom.1252 > English, New Zealand : English_United States.1252 > English_New Zealand : English_New Zealand.1252 > > There are some interesting interpretations in the above, but I > understand they probably depend on the OS (Windows Vista, in this Bizzarre. > case). In the install-postgresql.log file I see attempts to get a list > of available system locales: > > Executing C:\Users\mwtoews\AppData\Local\Temp\postgresql_installer\getlocales.exe > Script exit code: 0 > > Script output: > AfrikaansxxCOMMAxxxxSPxxSouthxxSPxxAfrica=Afrikaans, South Africa > AlbanianxxCOMMAxxxxSPxxAlbania=Albanian, Albania You can ignore most of that - the weirdness there is just the format we present the data to the Bitrock installer code in for it to populate the list. Ugly as sin, but entirely generated from the local system. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Testing on another Windows OS, here is a similar key : value exercise,
described previously. The system is Windows 7 64-bit, with a system
locale: "en-nz;English (New Zealand)" (from systeminfo.exe). The
version of initdb.exe is 9.2.0, and the full command-line is:
>"C:\Program Files\PostgreSQL\9.2\bin\initdb.exe" --locale="key" --encoding=UTF-8 -D NUL
C : C
English : English_United States.1252
French : French_France.1252
nonsense : English_New Zealand.1252
displays initdb: invalid locale name "nonsense" 6 times
French, Canada : French_France.1252
French_Canada : French_Canada.1252
English, Canada : English_United States.1252
English_New_Zealand : English_New Zealand.1252
displays initdb: invalid locale name "English_New_Zealand" 6 times
English, New Zealand : English_United States.1252
English_New Zealand : English_New Zealand.1252
Interestingly, this OS displays "initdb: invalid locale name" (six
times), whereas I don't recall seeing that message with Vista. But it
doesn't tell me that "English, New Zealand" is invalid, while it
changes the locale to "English_United States.1252", which is puzzling.
-Mike
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
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
I think everything is covered by Mike here. "getlocales.exe" returns the list of locales in the format "Language, Country" for most of them. and this worked fine on 9.1, but does not work on 9.2. And if we are looking for a workaround in installer, then as Mike suggested, we should handle it in initcluster.vbs. (for 9.2.0) Mike, for the corner cases that you talked about, one worked for me if we keep the original format and do NOT replace the "," with "_". --- c:\Program Files\PostgreSQL\9.2>bin\ initdb.exe --locale=3D"Norwegian (Bokm=EF=BF=BDl), Norway" -D "c:\Program Files\PostgreSQL\9.2\data2" The files belonging to this database system will be owned by user "edb". This user must also own the server process. The database cluster will be initialized with locale "Norwegian (Bokm=EF=BF=BDl)_Norway. <=3D=3D --- For, the other two, I see the same behaviour. I'm using Win7, 32bit. Overall, we will have to test all the formats of the locales returned from getlocals.exe and check what works with initdb.exe in 9.2. On Fri, Sep 14, 2012 at 1:47 AM, Dave Page <dpage@pgadmin.org> wrote: > 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@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/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=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 > > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > --=20 Sandeep Thakkar Senior Software Engineer EnterpriseDB Corporation The Enterprise Postgres Company Phone: +91.20.30589514 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message.
I think everything is covered by Mike here. "getlocales.exe" returns the list of locales in the format "Language, Country" for most of them. and this worked fine on 9.1, but does not work on 9.2. And if we are looking for a workaround in installer, then as Mike suggested, we should handle it in initcluster.vbs. (for 9.2.0) Mike, for the corner cases that you talked about, one worked for me if we keep the original format and do NOT replace the "," with "_". --- c:\Program Files\PostgreSQL\9.2>bin\initdb.exe --locale=3D"Norwegian (Bokm=EF=BF=BDl), Norway" -D "c:\Program Files\PostgreSQL\9.2\data2" The files belonging to this database system will be owned by user "edb". This user must also own the server process. The database cluster will be initialized with locale "Norwegian (Bokm=EF=BF=BDl)_Norway. --- For, the other two, I see the same behaviour. I'm using Win7, 32bit from India. Overall, we will have to test all the formats of the locales returned from getlocals.exe and check what works with initdb.exe in 9.2. On Fri, Sep 14, 2012 at 1:47 AM, Dave Page <dpage@pgadmin.org> wrote: > 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@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/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=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 > > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > --=20 Sandeep Thakkar Senior Software Engineer EnterpriseDB Corporation The Enterprise Postgres Company Phone: +91.20.30589514 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message.
On Friday, September 14, 2012, Sandeep Thakkar wrote: > I think everything is covered by Mike here. "getlocales.exe" returns the > list of locales in the format "Language, Country" for most of them. and > this worked fine on 9.1, but does not work on 9.2. And if we are looking > for a workaround in installer, then as Mike suggested, we should handle it > in initcluster.vbs. (for 9.2.0) > Hmm, thanks Sandeep. So I believe the only thing that changed in this area between 9.1 and 9.2 is that we moved from VC++ 2008 to 2010. Can you confirm that's the only difference please, and that the output from getlocales does differ between versions when run on the same box? If that's the case, we can do the tweaking of the names there, but only when using the newer compiler, if we cannot find a better fix. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
No.. what I mean to say is that the output from getlocales is same in 9.1 and 9.2. (I checked the installation logs). It's initdb in 9.2 that is not accepting the same output. So, it has nothing to with the VC++ runtimes. PG9.1: -- c:\Program Files\PostgreSQL\9.1>bin\initdb.exe" --locale="English, New Zealand" -D "c:\Program Files\PostgreSQL\9.1\data2" The files belonging to this database system will be owned by user "edb". This user must also own the server process. The database cluster will be initialized with locale English, New Zealand. <-- OKAY -- PG9.2: -- c:\Program Files\PostgreSQL\9.2>bin\initdb.exe --locale="English, New Zealand" -D "c:\Program Files\PostgreSQL\9.2\data2" The files belonging to this database system will be owned by user "edb". This user must also own the server process. The database cluster will be initialized with locale "English_United States.1252 <--NOT OKAY -- Now, on 9.2, if we replace "," with "_" from the locale name, then it works fine: c:\Program Files\PostgreSQL\9.2>bin\initdb.exe" --locale="English_New Zealand" -D "c:\Program Files\PostgreSQL\data" The files belonging to this database system will be owned by user "edb". This user must also own the server process. The database cluster will be initialized with locale "English_New Zealand.1252". <-- OKAY -- So, actually it's initdb that has undergone change. Fix in initdbcluster.vbs so that the locale name is passed with "_" to initdb.exe, is just a workaround from installer. On Fri, Sep 14, 2012 at 3:11 PM, Dave Page <dpage@pgadmin.org> wrote: > > > On Friday, September 14, 2012, Sandeep Thakkar wrote: > >> I think everything is covered by Mike here. "getlocales.exe" returns the >> list of locales in the format "Language, Country" for most of them. and >> this worked fine on 9.1, but does not work on 9.2. And if we are looking >> for a workaround in installer, then as Mike suggested, we should handle it >> in initcluster.vbs. (for 9.2.0) >> > > Hmm, thanks Sandeep. So I believe the only thing that changed in this area > between 9.1 and 9.2 is that we moved from VC++ 2008 to 2010. Can you > confirm that's the only difference please, and that the output from > getlocales does differ between versions when run on the same box? > > If that's the case, we can do the tweaking of the names there, but only > when using the newer compiler, if we cannot find a better fix. > > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > -- Sandeep Thakkar Senior Software Engineer EnterpriseDB Corporation The Enterprise Postgres Company Phone: +91.20.30589514 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message.
On Fri, Sep 14, 2012 at 6:14 AM, Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> wrote: > No.. what I mean to say is that the output from getlocales is same in 9.1 > and 9.2. (I checked the installation logs). It's initdb in 9.2 that is not > accepting the same output. So, it has nothing to with the VC++ runtimes. Ah, OK. Sorry - misunderstood what you were saying. I guess it could still be the runtimes, but affecting initdb, though a quick look at the initdb commit logs shows this http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a88b6e4cfbff9802906dd400ef334ffa49e7f286, which I'd immediately suspect as at least part of the culprit, except that it was apparently backported to 9.1. > PG9.1: > -- > c:\Program Files\PostgreSQL\9.1>bin\initdb.exe" --locale="English, New > Zealand" -D "c:\Program Files\PostgreSQL\9.1\data2" > > The files belonging to this database system will be owned by user "edb". > This user must also own the server process. > > The database cluster will be initialized with locale English, New Zealand. > <-- OKAY > -- > > PG9.2: > -- > c:\Program Files\PostgreSQL\9.2>bin\initdb.exe --locale="English, New > Zealand" -D "c:\Program Files\PostgreSQL\9.2\data2" > > The files belonging to this database system will be owned by user "edb". > This user must also own the server process. > > The database cluster will be initialized with locale "English_United > States.1252 <--NOT OKAY > -- > > Now, on 9.2, if we replace "," with "_" from the locale name, then it works > fine: > c:\Program Files\PostgreSQL\9.2>bin\initdb.exe" --locale="English_New > Zealand" -D "c:\Program Files\PostgreSQL\data" > > The files belonging to this database system will be owned by user "edb". > This user must also own the server process. > > The database cluster will be initialized with locale "English_New > Zealand.1252". <-- OKAY > -- > > So, actually it's initdb that has undergone change. Fix in initdbcluster.vbs > so that the locale name is passed with "_" to initdb.exe, is just a > workaround from installer. > > > On Fri, Sep 14, 2012 at 3:11 PM, Dave Page <dpage@pgadmin.org> wrote: >> >> >> >> On Friday, September 14, 2012, Sandeep Thakkar wrote: >>> >>> I think everything is covered by Mike here. "getlocales.exe" returns the >>> list of locales in the format "Language, Country" for most of them. and this >>> worked fine on 9.1, but does not work on 9.2. And if we are looking for a >>> workaround in installer, then as Mike suggested, we should handle it in >>> initcluster.vbs. (for 9.2.0) >> >> >> Hmm, thanks Sandeep. So I believe the only thing that changed in this area >> between 9.1 and 9.2 is that we moved from VC++ 2008 to 2010. Can you confirm >> that's the only difference please, and that the output from getlocales does >> differ between versions when run on the same box? >> >> If that's the case, we can do the tweaking of the names there, but only >> when using the newer compiler, if we cannot find a better fix. >> >> >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> > > > > -- > Sandeep Thakkar > Senior Software Engineer > EnterpriseDB Corporation > The Enterprise Postgres Company > Phone: +91.20.30589514 > > Website: www.enterprisedb.com > EnterpriseDB Blog: http://blogs.enterprisedb.com/ > Follow us on Twitter: http://www.twitter.com/enterprisedb > > This e-mail message (and any attachment) is intended for the use of the > individual or entity to whom it is addressed. This message contains > information from EnterpriseDB Corporation that may be privileged, > confidential, or exempt from disclosure under applicable law. If you are not > the intended recipient or authorized to receive this for the intended > recipient, any use, dissemination, distribution, retention, archiving, or > copying of this communication is strictly prohibited. If you have received > this e-mail in error, please notify the sender immediately by reply e-mail > and delete this message. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
I note also that two of the special case locales Mike found are ones that are supposed to be handled properly by that patch (they have dots in the name). Here's an earlier attempt, which I believe the second patch was intended to complement: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=d5a7bf8c11c8b66c822bbb1a6c90e1a14425bd6e On Fri, Sep 14, 2012 at 6:54 AM, Dave Page <dpage@pgadmin.org> wrote: > On Fri, Sep 14, 2012 at 6:14 AM, Sandeep Thakkar > <sandeep.thakkar@enterprisedb.com> wrote: >> No.. what I mean to say is that the output from getlocales is same in 9.1 >> and 9.2. (I checked the installation logs). It's initdb in 9.2 that is not >> accepting the same output. So, it has nothing to with the VC++ runtimes. > > Ah, OK. Sorry - misunderstood what you were saying. I guess it could > still be the runtimes, but affecting initdb, though a quick look at > the initdb commit logs shows this > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a88b6e4cfbff9802906dd400ef334ffa49e7f286, > which I'd immediately suspect as at least part of the culprit, except > that it was apparently backported to 9.1. > >> PG9.1: >> -- >> c:\Program Files\PostgreSQL\9.1>bin\initdb.exe" --locale="English, New >> Zealand" -D "c:\Program Files\PostgreSQL\9.1\data2" >> >> The files belonging to this database system will be owned by user "edb". >> This user must also own the server process. >> >> The database cluster will be initialized with locale English, New Zealand. >> <-- OKAY >> -- >> >> PG9.2: >> -- >> c:\Program Files\PostgreSQL\9.2>bin\initdb.exe --locale="English, New >> Zealand" -D "c:\Program Files\PostgreSQL\9.2\data2" >> >> The files belonging to this database system will be owned by user "edb". >> This user must also own the server process. >> >> The database cluster will be initialized with locale "English_United >> States.1252 <--NOT OKAY >> -- >> >> Now, on 9.2, if we replace "," with "_" from the locale name, then it works >> fine: >> c:\Program Files\PostgreSQL\9.2>bin\initdb.exe" --locale="English_New >> Zealand" -D "c:\Program Files\PostgreSQL\data" >> >> The files belonging to this database system will be owned by user "edb". >> This user must also own the server process. >> >> The database cluster will be initialized with locale "English_New >> Zealand.1252". <-- OKAY >> -- >> >> So, actually it's initdb that has undergone change. Fix in initdbcluster.vbs >> so that the locale name is passed with "_" to initdb.exe, is just a >> workaround from installer. >> >> >> On Fri, Sep 14, 2012 at 3:11 PM, Dave Page <dpage@pgadmin.org> wrote: >>> >>> >>> >>> On Friday, September 14, 2012, Sandeep Thakkar wrote: >>>> >>>> I think everything is covered by Mike here. "getlocales.exe" returns the >>>> list of locales in the format "Language, Country" for most of them. and this >>>> worked fine on 9.1, but does not work on 9.2. And if we are looking for a >>>> workaround in installer, then as Mike suggested, we should handle it in >>>> initcluster.vbs. (for 9.2.0) >>> >>> >>> Hmm, thanks Sandeep. So I believe the only thing that changed in this area >>> between 9.1 and 9.2 is that we moved from VC++ 2008 to 2010. Can you confirm >>> that's the only difference please, and that the output from getlocales does >>> differ between versions when run on the same box? >>> >>> If that's the case, we can do the tweaking of the names there, but only >>> when using the newer compiler, if we cannot find a better fix. >>> >>> >>> >>> -- >>> Dave Page >>> Blog: http://pgsnake.blogspot.com >>> Twitter: @pgsnake >>> >>> EnterpriseDB UK: http://www.enterprisedb.com >>> The Enterprise PostgreSQL Company >>> >> >> >> >> -- >> Sandeep Thakkar >> Senior Software Engineer >> EnterpriseDB Corporation >> The Enterprise Postgres Company >> Phone: +91.20.30589514 >> >> Website: www.enterprisedb.com >> EnterpriseDB Blog: http://blogs.enterprisedb.com/ >> Follow us on Twitter: http://www.twitter.com/enterprisedb >> >> This e-mail message (and any attachment) is intended for the use of the >> individual or entity to whom it is addressed. This message contains >> information from EnterpriseDB Corporation that may be privileged, >> confidential, or exempt from disclosure under applicable law. If you are not >> the intended recipient or authorized to receive this for the intended >> recipient, any use, dissemination, distribution, retention, archiving, or >> copying of this communication is strictly prohibited. If you have received >> this e-mail in error, please notify the sender immediately by reply e-mail >> and delete this message. > > > > -- > Dave Page > Blog: http://pgsnake.blogspot.com > Twitter: @pgsnake > > EnterpriseDB UK: http://www.enterprisedb.com > The Enterprise PostgreSQL Company -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Dave Page <dpage@pgadmin.org> writes: > On Fri, Sep 14, 2012 at 6:14 AM, Sandeep Thakkar > <sandeep.thakkar@enterprisedb.com> wrote: >> No.. what I mean to say is that the output from getlocales is same in 9.1 >> and 9.2. (I checked the installation logs). It's initdb in 9.2 that is not >> accepting the same output. So, it has nothing to with the VC++ runtimes. > Ah, OK. Sorry - misunderstood what you were saying. I guess it could > still be the runtimes, but affecting initdb, though a quick look at > the initdb commit logs shows this > http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a88b6e4cfbff9802906dd400ef334ffa49e7f286, > which I'd immediately suspect as at least part of the culprit, except > that it was apparently backported to 9.1. Actually, 9.2 intentionally tries to canonicalize locale names, see commit c7cea267de3ca05b29a57b9d113b95ef3793c8d8. Microsoft's support of setlocale seems to be shoddy enough that it wouldn't be surprising if there were some issue there. regards, tom lane
On Fri, Sep 14, 2012 at 10:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Dave Page <dpage@pgadmin.org> writes: >> On Fri, Sep 14, 2012 at 6:14 AM, Sandeep Thakkar >> <sandeep.thakkar@enterprisedb.com> wrote: >>> No.. what I mean to say is that the output from getlocales is same in 9.1 >>> and 9.2. (I checked the installation logs). It's initdb in 9.2 that is not >>> accepting the same output. So, it has nothing to with the VC++ runtimes. > >> Ah, OK. Sorry - misunderstood what you were saying. I guess it could >> still be the runtimes, but affecting initdb, though a quick look at >> the initdb commit logs shows this >> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a88b6e4cfbff9802906dd400ef334ffa49e7f286, >> which I'd immediately suspect as at least part of the culprit, except >> that it was apparently backported to 9.1. > > Actually, 9.2 intentionally tries to canonicalize locale names, see > commit c7cea267de3ca05b29a57b9d113b95ef3793c8d8. Microsoft's support > of setlocale seems to be shoddy enough that it wouldn't be surprising > if there were some issue there. Oh, OK - thanks for the pointer. I guess this needs further investigation on Windows - I know I'm not likely to be able to look at it for at least a couple of weeks, so if anyone else can... -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company