Re: define bool in pgtypeslib_extern.h - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: define bool in pgtypeslib_extern.h
Date
Msg-id CAA4eK1J7KrJkG-NjvHHCG9UjwnBeJ67FhgZ_Y2feNFpx1QaXNw@mail.gmail.com
Whole thread Raw
In response to Re: define bool in pgtypeslib_extern.h  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Nov 8, 2019 at 2:17 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
> > I'm inclined to think that we need to make ecpglib.h's bool-related
> > definitions exactly match c.h, which will mean that it has to pull in
> > <stdbool.h> on most platforms, which will mean adding a control symbol
> > for that to ecpg_config.h.  I do not think we should export
> > HAVE_STDBOOL_H and SIZEOF_BOOL there though; probably better to have
> > configure make the choice and export something named like PG_USE_STDBOOL.
>
> Here's a proposed patch that does it like that.
>
> I'm of two minds about whether to back-patch or not.  This shouldn't
> really change anything except on platforms where sizeof(_Bool) isn't
> one.  We have some reason to think that nobody is actually using
> ecpg on such platforms :-(, because if they were, they'd likely have
> complained about breakage.
>

Yeah, this is a valid point, but I think this would have caused
breakage only after d26a810eb which is a recent change.  If that is
right, then I am not sure such an assumption is safe.  Also, we have
already backpatched the probes.d change, so it seems reasonable to
make this change and keep the bool definition consistent in code.
OTOH, I think there is no harm in making this change for HEAD and if
later we face any complaint, we can backpatch it.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Collation versioning
Next
From: Thomas Munro
Date:
Subject: Re: Parallel leader process info in EXPLAIN