From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Kapila <amit.kapila16@gmail.com>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
        Andrew Gierth <andrew@tao11.riddles.org.uk>
Subject: Re: define bool in pgtypeslib_extern.h
In-reply-to: <16583.1572010913@sss.pgh.pa.us>
References: 
 <CAA4eK1LmaKO7Du9M9Lo=kxGU8sB6aL8fa3sF6z6d5yYYVe3BuQ@mail.gmail.com>
 <16583.1572010913@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 25 Oct 2019 09:41:53 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <18577.1572020755.1@sss.pgh.pa.us>
Date: Fri, 25 Oct 2019 12:25:55 -0400
Message-ID: <18578.1572020755@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Amit Kapila <amit.kapila16@gmail.com> writes:
>> As suggested by Andrew Gierth [1], I think we can remove the define in
>> pgtypeslib_extern.h as it doesn't seem to be exposed.

> Yeah, it's not good that that results in a header ordering dependency,
> and it doesn't seem like a good idea for pgtypeslib_extern.h to be
> messing with the issue at all.
> If you like, I can experiment with that locally on prairiedog's host
> before we make the buildfarm jump through hoops.

I checked that that works and fixes the immediate problem, so I pushed
it.  However, we're not out of the woods, because lookee here in
ecpglib.h:

#ifndef __cplusplus
#ifndef bool
#define bool char
#endif                          /* ndef bool */

#ifndef true
#define true    ((bool) 1)
#endif                          /* ndef true */
#ifndef false
#define false   ((bool) 0)
#endif                          /* ndef false */
#endif                          /* not C++ */

#ifndef TRUE
#define TRUE    1
#endif                          /* TRUE */

#ifndef FALSE
#define FALSE   0
#endif                          /* FALSE */

This stuff *is* exposed to client programs, so it's not clear how
painless it'd be to monkey around with it.  And it is used, further
down in the same file, so we can't fix it just by deleting it.
Nor can we import c.h to get the "real" definition from that.

I'm more than slightly surprised that we haven't already seen
problems due to this conflicting with d26a810eb.  I've not bothered
to run to ground exactly why not, though.

Thoughts?

			regards, tom lane