* Alvaro Herrera wrote:
> Michael Paquier wrote:
>> On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> Now, I have produced two patches:
>>> - 0001-Support-for-VS-2015-locale-hack.patch, which makes use of
>>> __crt_locale_data_public in ucrt/corecrt.h. This is definitely an ugly
>>> hack, though I am coming to think that this may be the approach that
>>> would us the less harm, and that's closer to what is done for VS 2012
>>> and 2013.
>>> - 0001-Support-for-VS-2015-getlocaleinfoex.patch, which make use of
>>> GetLocaleInfoEx, this requires us to lower a bit the support grid for
>>> Windows, basically that's throwing support for XP if compilation is
>>> done with VS 2015.
>>> Based on my tests, both are working with short and long local names,
>>> testing via initdb --locale.
>>
>> The first patch is actually not what I wanted to send. Here are the
>> correct ones...
>
> This thread seems to have stalled. I thought we were going to consider
> these patches for 9.6. Should we simply push them to see what the
> buildfarm thinks? Has anyone other than Michael actually tested it in
> VS2015?
I built them both, and for lack of a better idea, ran initdb with all
(short) locales in the Vista list
(https://msdn.microsoft.com/en-us/goglobal/bb896001.aspx, second column)
whose ANSI codepage is not either 0 or 1252. The former probably means
"no such thing", the latter is my own default which I excluded to detect
cases where it falls back to that.
Both patches behave exactly the same in this test. Of the 102 remaining
locales, I get an unexpected codepage for just four:
- kk: Expected 1251, used 1252
- kk-KZ: Expected 1251, used 1252
- sr: Expected 1251, used 1250
- uk: Expected 1251, used 1252
I suspect that "sr" is a bug in MSDN: 1250 is Eastern European (Latin),
1251 is Cyrillic, and "sr" alone is listed as Latin. So either the
script or the codepage are likely wrong.
--
Christian
