* Alvaro Herrera wrote:
Michael Paquier wrote:
On Mon, Apr 11, 2016 at 3:25 PM, Michael Paquier
<michael.paqu...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
