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

On Tue, Apr 21, 2020 at 12:51 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Apr 20, 2020 at 6:32 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Sun, Apr 19, 2020 at 3:46 PM Juan José Santamaría Flecha
> > <juanjo.santamaria@gmail.com> wrote:
> > >
> > > I cannot find a single place where all supported locales are listed, but I have created a small test program
(WindowsNLSLocales.c)based on: <language>[_<location>] format locales [1], additional supported language strings [2],
andadditional supported country and region strings [3]. Based on the results from this test program, it is possible to
todo a good job with the <language>[_<location>] types using the proposed logic, but the two later cases are Windows
specific,and there is no way arround a lookup-table. 
> > >
> > > The attached results (WindowsNLSLocales.ods) come from Windows 10 (1903) and Visual C++ build 1924, 64-bit.
> > >
> >
> > I think these are quite intensive tests but I wonder do we need to
> > test some locales with code_page?  Generally speaking, in this case it
> > should not matter as we are trying to get the locale name but no harm
> > in testing.  Also, I think it would be good if we can test how this
> > impacts the error messages as Davinder is trying to do.
> >
>
>
> I have tried a simple test with the latest patch and it failed for me.
>
> Set LC_MESSAGES="English_United Kingdom";
> -- returns en-GB, then code changes it to en_NZ when _create_locale()
> is used whereas with the patch it returns "" (empty string).
>
> There seem to be two problems here (a) The input to enum_locales_fn
> doesn't seem to get the input name as "English_United Kingdom" due to
> which it can't find a match even if the same exists. (b) After
> executing EnumSystemLocalesEx, there is no way the patch can detect if
> it is successful in finding the passed name due to which it appends
> empty string in such cases.
>

Few more comments:
1. I have tried the first one in the list provided by you and that
also didn't work. Basically, I got  empty string when I tried Set
LC_MESSAGES='Afar';

2. Getting below warning
pg_locale.c(1072): warning C4133: 'function': incompatible types -
from 'const char *' to 'const wchar_t *'

3.
+ if (GetLocaleInfoEx(pStr, LOCALE_SENGLISHCOUNTRYNAME,
+ test_locale + len, LOCALE_NAME_MAX_LENGTH - len) > 0)

All > or <= 0 checks should be changed to "!" types which mean to
check whether the call toGetLocaleInfoEx is success or not.

4. In the patch, first, we try to get with LCType as LOCALE_SNAME and
then with LOCALE_SENGLISHLANGUAGENAME and LOCALE_SENGLISHCOUNTRYNAME.
I think we should add comments indicating why we try to get the locale
information with three LCTypes and why the specific order of trying
those types is required.

5. In one of the previous emails, you asked whether we have a list of
supported locales.  I don't find any such list. I think it depends on
Windows locales for which you can get the information from
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9c

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com