Re: GinPageIs* don't actually return a boolean

On Thu, Feb 11, 2016 at 9:30 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> 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.

OK, that seems reasonable from here.  What I'm still fuzzy about is
why including stdbool.h causes a failure. Is it because it defines a
type called "bool" that clashes with ours?  That seems like the
obvious explanation, but then how does that not cause the compiler to
just straight-up error out?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company