Re: PostgreSQL 12 installation fails because locale name contained non-english characters

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Skjalg A(dot) Skagen" <skjalg(dot)skagen(at)pm(dot)me>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: PostgreSQL 12 installation fails because locale name contained non-english characters
Date: 2019-11-06 15:29:29
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs pgsql-hackers

"Skjalg A. Skagen" <skjalg(dot)skagen(at)pm(dot)me> writes:
> If you mean what I see in the drop-down menu during installation, I see "Norwegian Bokmål, Norway" -- identical to what getlocales.exe reported in my installation log file on line 222:

OK, thanks for confirming. So the committed patch does *not* add enough
flexibility to cover this case.

I wrote:
>> I wonder whether we need to relax the matching code to be entirely
>> agnostic about spaces and punctuation in the Windows locale name.

After googling a little bit, I could not find any indication that
Microsoft promises anything at all about the stability of these
long-form locale names. They document short names similar to the
Unix conventions, e.g. "en-US" and "nb-NO", as being the stable
forms that applications are encouraged to use. So somewhere there
is code that converts these long-form names to the standardized
representation, and it would be entirely reasonable for that code
to try to be forgiving. Thus, it's no surprise that we're getting
bit by small variations like these.

I'm inclined to think that we ought to ignore anything that isn't
an ASCII letter while trying to match these locale names. That's
a little bit problematic in terms of what win32setlocale.c does
today, because it tries to replace "just the matched string",
but it'd be unclear where the match ends if there are ignorable
characters. But probably we could change it so that it just takes
the translation and then tacks on ".NNNN" if the input ends with
a dot and digits.

Maybe case insensitivity would be a good idea too? The existing
code hasn't got that refinement, so maybe it's not important,
but the examples I'm seeing in places like

are all-lower-case.

regards, tom lane

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2019-11-06 15:32:56 Re: BUG #16095: Segfault while executing trigger
Previous Message PG Bug reporting form 2019-11-06 15:28:28 BUG #16097: ts_headline fails on text with html style tag

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2019-11-06 15:35:18 Re: Checking return value of SPI_execute
Previous Message Alvaro Herrera 2019-11-06 15:11:12 Re: Checking return value of SPI_execute