Re: VS 2015 support in src/tools/msvc - Mailing list pgsql-hackers

On Wed, Apr 20, 2016 at 1:39 PM, Noah Misch <noah@leadboat.com> wrote:
> On Tue, Apr 19, 2016 at 02:42:24AM -0300, 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.
>
> Committers have given this thread's patches a generous level of consideration.
> At this point, if $you wouldn't back-patch them to at least 9.5, they don't
> belong in 9.6.  However, a back-patch to 9.3 does seem fair, assuming the
> final patch looks anything like the current proposals.

Er, the change is rather located and fully controlled by _MSC_VER >=
1900, so this represents no risk for existing compilations on Windows,
don't you agree? With HEAD, code compilation would just fail btw
knowing how locales are broken, so it would just not work. That said,
support for new VS versions have been backpatched to the last stable
version at least, now that would be 9.5. There is indeed no written
policy stating what to do precisely in this case, but it seems to me
that there is no point in being overly protective as well..

>> Should we simply push them to see what the
>> buildfarm thinks?
>
> No.  The thread has been getting suitable test reports for a few weeks now.
> If it were not, better to make the enhancement wait as long as necessary than
> to use the buildfarm that way.  Buildfarm results wouldn't even be pertinent;
> they would merely tell us whether the patch broke non-VS 2015 compilers.

Well, they could push them, the results won't really matter and
existing machines won't be impacted, as no buildfarm machine is using
_MSC_VER >= 1900 as of now. Petr has one ready though as mentioned
upthread.
-- 
Michael