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.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com