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

From Juan José Santamaría Flecha
Subject Re: PG compilation error with Visual Studio 2015/2017/2019
Date
Msg-id CAC+AXB06EBrTcD1a4O1GFfAYmMvrsvY4jQPS63LznahxLi-qxA@mail.gmail.com
Whole thread Raw
In response to Re: PG compilation error with Visual Studio 2015/2017/2019  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: PG compilation error with Visual Studio 2015/2017/2019  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers

On Thu, Apr 23, 2020 at 5:30 AM Amit Kapila <amit.kapila16@gmail.com> wrote:

Okay, I hope we will see better comments in the next version.

I have focused on improving comments in this version.
 
Hmm, if you really want to log the value then do it in the caller.  I
don't think making special arrangements just for logging this value is
a good idea.

Agreed.
 
I think we can check with simple error messages.  So, basically after
setting a particular value of LC_MESSAGES, execute a query which
returns syntax or any other error, if the error message is the same
irrespective of the locale name returned by _create_locale and
GetLocaleInfoEx, then we should be fine.  I want to especially try
where the return value is slightly different by _create_locale and
GetLocaleInfoEx.   I know Davinder is trying something like this but
if you can also try then it would be good.

I have composed a small set of queries to test the output with different lc_message settings (lc_messages_test.sql). Please find attached the output from debug3 logging using both EnumSystemLocalesEx (lc_messages_EnumSystemLocalesEx.log) and _create_locale (lc_messages_create_locale.log).

> In Windows  wchar_t is 2 bytes, so we would have to do make UTF16 to UFT32 conversions back and forth. Not sure if it is worth the effort.

Yeah, I am also not sure about this.  So, let us see if anyone else
has any thoughts on this point, otherwise, we can go with wchar
functions as you have in the patch.

Ok, the attached version still uses that approach.

Regards,

Juan José Santamaría Flecha
Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Parallel Append can break run-time partition pruning
Next
From: Robert Haas
Date:
Subject: Re: +(pg_lsn, int8) and -(pg_lsn, int8) operators