Re: PG compilation error with Visual Studio 2015/2017/2019 - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: PG compilation error with Visual Studio 2015/2017/2019
Date
Msg-id CAA4eK1+xF1qtt_EWiMTbpUoRow_EZN1CqXWhpE_GWjhGkrHm4A@mail.gmail.com
Whole thread Raw
In response to Re: PG compilation error with Visual Studio 2015/2017/2019  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: PG compilation error with Visual Studio 2015/2017/2019
List pgsql-hackers
On Fri, Apr 10, 2020 at 5:35 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Tue, Apr 7, 2020 at 8:30 PM Juan José Santamaría Flecha
> <juanjo.santamaria@gmail.com> wrote:
> >
> > * I think you could save a couple of code lines, and make it clearer, by merging both tests on  _MSC_VER  into a
single#if... #else and leaving as common code: 
> > + }
> > + else
> > + return NULL;
> > +#endif /*_MSC_VER && _MSC_VER < 1900*/
> >
> > * The logic on "defined(_MSC_VER) && (_MSC_VER >= 1900)" is defined as "_WIN32_WINNT >= 0x0600" on other parts of
thecode. I would recommend using the later. 
> >
>
> I see that we have used _MSC_VER form of checks in win32_langinfo
> (chklocale.c) for a similar kind of handling.  So, isn't it better to
> be consistent with that?  Which exact part of the code you are
> referring to?
>

I see that the kind of check you are talking is recently added by
commit 352f6f2d.  I think it is better to be consistent in all places.
Let's pick one and use that if possible.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andreas Karlsson
Date:
Subject: Re: Support for DATETIMEOFFSET
Next
From: Fujii Masao
Date:
Subject: Re: SyncRepLock acquired exclusively in default configuration