Re: GinPageIs* don't actually return a boolean

On Thu, Feb 11, 2016 at 9:30 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Fri, Feb 12, 2016 at 3:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Andres Freund <andres(at)anarazel(dot)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