On Thu, Feb 11, 2016 at 9:30 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Fri, Feb 12, 2016 at 3:45 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
