Re: PostgreSQL 12 installation fails because locale name contained non-english characters
От | Tom Lane |
---|---|
Тема | Re: PostgreSQL 12 installation fails because locale name contained non-english characters |
Дата | |
Msg-id | 28361.1573054169@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PostgreSQL 12 installation fails because locale name contained non-english characters ("Skjalg A. Skagen" <skjalg.skagen@pm.me>) |
Ответы |
Re: PostgreSQL 12 installation fails because locale name contained non-english characters
Re: PostgreSQL 12 installation fails because locale name contained non-english characters |
Список | pgsql-bugs |
"Skjalg A. Skagen" <skjalg.skagen@pm.me> writes: > If you mean what I see in the drop-down menu during installation, I see "Norwegian Bokmål, Norway" -- identical to whatgetlocales.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 https://docs.microsoft.com/en-us/cpp/c-runtime-library/language-strings?view=vs-2019 are all-lower-case. regards, tom lane
В списке pgsql-bugs по дате отправления: