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

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
> https://docs.microsoft.com/en-us/cpp/c-runtime-library/language-strings?view=vs-2019
> are all-lower-case.

Here's a draft patch for that. I've checked that the logic does
what I expect, but I don't have a way to actually test this thing
in a Windows build. Anyone?

regards, tom lane