On 22/03/16 14:40, Michael Paquier wrote:
On Wed, Mar 9, 2016 at 11:10 PM, Petr Jelinek <p...@2ndquadrant.com> wrote:
Something like attached is simplest way this would work correctly (note that
I didn't really test it and it's missing comments). Note that we are falling
back to the old parsing in case the GetLocaleInfoEx didn't work, that's
important because GetLocaleInfoEx does not support the
<Language>_<Country>.<CodePage> format but supports all the rest of them.
The problem with this is the binaries would need to be compiled with target
of vista/windows server 2008+. That would be of course only the case with
builds made with VS2015, so I am not sure if we care all that much
(especially given the fact that older windows are not supported by MS
anyway).
Ah, OK. Of course.
I don't currently know of any way of doing this in VS2015 that would work
with older versions of windows with the exception of having our own
definition of the locale_t struct so that the VS2013 code would still
work...
There is no actual way to be sure if this is an intentional change or
not, if we see it back in the next version of VS, why not... I would
like to think like you that this is actually a merge mistake from
Redmond-side, but I think we had better be careful here, this could
lead to undetected errors in the future.
Sure, I am looking at it from the perspective that they didn't even
deprecate the function and changes to the struct it returns would break
binary compatibility for existing apps.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
