PG compilation error with Visual Studio 2015/2017/2019 - Mailing list pgsql-hackers

From davinder singh
Subject PG compilation error with Visual Studio 2015/2017/2019
Date
Msg-id CAHzhFSFoJEWezR96um4-rg5W6m2Rj9Ud2CNZvV4NWc9tXV7aXQ@mail.gmail.com
Whole thread Raw
Responses Re: PG compilation error with Visual Studio 2015/2017/2019  (Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>)
Re: PG compilation error with Visual Studio 2015/2017/2019  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Hi All,

I am working on “pg_locale compilation error with Visual Studio 2017”, Related threads[1],[2].
We are getting compilation error in static char *IsoLocaleName(const char *winlocname) function in pg_locale.c file. This function is trying to convert the locale name into the Unix style. For example, it will change the locale name "en-US" into "en_US".
It is creating a locale using _locale_t _create_locale( int category, const char *locale) and then trying to access the name of that locale by pointing to internal elements of the structure loct->locinfo->locale_name[LC_CTYPE] but it has been missing from the _locale_t since VS2015 which is causing the compilation error. I found a few useful APIs that can be used here.

ResolveLocaleName and GetLocaleInfoEx both can take locale in the following format.
<language>-<REGION>
<language>-<Script>-<REGION>

ResolveLocaleName will try to find the closest matching locale name to the input locale name even if the input locale name is invalid given that the <language> is correct.
en-something-YZ     => en-US
ex-US                      => error
Aa-aaaa-aa             => aa-ET   represents (Afar,Ethiopia)
Aa-aaa-aa               => aa-ET
Refer [4] for more details

But in the case of GetLocaleInfoEx, it will only check the format of the input locale, as mentioned before, if correct it will return the name of the locale otherwise it will return an error.
For example.
en-something-YZ     => error
ex-US                       => ex-US
aa-aaaa-aa              => aa-Aaaa-AA
aa-aaa-aa                => error.
Refer [5] for more details.

Currently, it is using _create_locale it behaves similarly to GetLocaleInfoEx i.e. it also only checks the format only difference is for a bigger set.
I thought of using GetLocaleInfoEx for the fix because it behaves similarly to the already existing and a similar issue was resolved earlier using the same. I have attached the patch, let me know your thoughts.

[1] https://www.postgresql.org/message-id/e317eec9-d40d-49b9-b776-e89cf1d18c82@postgrespro.ru
[2] https://www.postgresql.org/message-id/23073.1526049547%40sss.pgh.pa.us
[3] https://docs.microsoft.com/en-us/windows/win32/intl/locale-names
[4] https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-resolvelocalename
[5] https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getlocaleinfoex
--
Regards,
Davinder.
Attachment

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: [HACKERS] Restricting maximum keep segments by repslots
Next
From: Michael Banck
Date:
Subject: [patch] Fix pg_checksums to allow checking of offline base backupdirectories