On Thu, Apr 23, 2020 at 5:30 AM Amit Kapila <amit.kapil...@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
0001-PG-compilation-error-with-VS-2015-2017-2019_v13.patch
Description: Binary data
lc_messages_create_locale.log
Description: Binary data
lc_messages_EnumSystemLocalesEx.log
Description: Binary data
lc_messages_test.sql
Description: Binary data
