Re: GinPageIs* don't actually return a boolean - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: GinPageIs* don't actually return a boolean
Date
Msg-id CAB7nPqTDiXxS8CdL8mOiVh6qFQ-1qV9mKN0AyjzYBvzv6WC0dA@mail.gmail.com
Whole thread Raw
In response to Re: GinPageIs* don't actually return a boolean  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: GinPageIs* don't actually return a boolean
Re: GinPageIs* don't actually return a boolean
List pgsql-hackers
On Fri, Feb 12, 2016 at 3:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2016-02-11 13:37:17 -0500, Tom Lane wrote:
>>> Absolutely; they don't work safely for testing bits that aren't in the
>>> rightmost byte of a flag word, for instance.  I'm on board with making
>>> these fixes, I'm just unconvinced that stdbool is a good reason for it.
>
>> Oh, ok. Interactions with stdbool was what made me looking into this,
>> that's primarily why I mentioned it.   What's your thinking about
>> back-patching, independent of that then?
>
> Well, Yury was saying upthread that some MSVC versions have a problem
> with the existing coding, which would be a reason to back-patch ...
> but I'd like to see a failing buildfarm member first.  Don't particularly
> want to promise to support compilers not represented in the farm.

Grmbl. Forgot to attach the rebased patch upthread. Here is it now.

As of now the only complain has been related to MS2015 and MS2013. If
we follow the pattern of cec8394b and [1], support to compile on newer
versions of MSVC would be master and REL9_5_STABLE, but MS2013 is
supported down to 9.3. Based on this reason, we would want to
backpatch down to 9.3 the patch of this thread.

[1]: http://www.postgresql.org/message-id/529D05CC.7070806@gmx.de
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Tracing down buildfarm "postmaster does not shut down" failures
Next
From: Amit Kapila
Date:
Subject: Re: [PATCH] Refactoring of LWLock tranches