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

From Ranier Vilela
Subject Re: PG compilation error with Visual Studio 2015/2017/2019
Date
Msg-id CAEudQAoFcXDSeZgk1EML-qMVVyTN4=tgqd-GNi3Vtz0bO=XJnA@mail.gmail.com
Whole thread Raw
In response to Re: PG compilation error with Visual Studio 2015/2017/2019  (Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>)
Responses Re: PG compilation error with Visual Studio 2015/2017/2019  (Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>)
List pgsql-hackers
Em dom., 19 de abr. de 2020 às 07:16, Juan José Santamaría Flecha <juanjo.santamaria@gmail.com> escreveu:

On Sat, Apr 18, 2020 at 6:07 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Sat, Apr 18, 2020 at 12:14 AM Juan José Santamaría Flecha
<juanjo.santamaria@gmail.com> wrote:
>
> We can get a match for those locales in non-ISO format by enumerating available locales with EnumSystemLocalesEx(), and trying to find a match.

I have not reviewed or tested the new patch but one thing I would like
to see is the impact of setting LC_MESAGGES with different locale
information.  Basically, the error messages after setting the locale
with _create_locale and with the new method being discussed.  This
will help us in ensuring that we didn't break anything which was
working with prior versions of MSVC.  Can you or someone try to test
and share the results of the same?

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], and additional supported country and region strings [3]. Based on the results from this test program, it is possible to to do 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.

On Sat, Apr 18, 2020 at 1:43 PM Ranier Vilela <ranier.vf@gmail.com> wrote:
I have some observations about this patch, related to style, if you will allow me. 

Please find attached a revised version.
Looks good to me, but, sorry, I think I missed a glitch in the previous review..

+#else /* _WIN32_WINNT < 0x0600 */
+ _locale_t loct;
+
+ loct = _create_locale(LC_CTYPE, winlocname);
+ if (loct != NULL)
+{
+ rc = wchar2char(iso_lc_messages, loct->locinfo->locale_name[LC_CTYPE],
+ sizeof(iso_lc_messages), NULL);
  _free_locale(loct);
+}
+#endif /* _WIN32_WINNT >= 0x0600 */

If _create_locale fail, no need to call _free_locale(loct);.

Another point is, what is the difference between pg_mbstrlen and wcslen?
It would not be better to use only wcslen?

Attached have the patch with this comments.

regards,
Ranier Vilela
Attachment

pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: WIP: WAL prefetch (another approach)
Next
From: Peter Eisentraut
Date:
Subject: HEAPDEBUGALL is broken