Re: [HACKERS] taking stdbool.h into use

On Sat, Dec 30, 2017 at 10:31:45AM -0500, Tom Lane wrote:
> Surely bool and bool8 should have identical Datum representations,
> so I'm not sure they need different DatumGet/GetDatum macros.

[... refresh update ...]
Yeah sure. I am a bit disturbed by the fact that DatumGetBool() enforces
a case to bool though.

> Although this opens up another point: just above those macros,
> postgres.h says
> 
>  * When a type narrower than Datum is stored in a Datum, we place it in the
>  * low-order bits and are careful that the DatumGetXXX macro for it discards
>  * the unused high-order bits (as opposed to, say, assuming they are zero).
>  * This is needed to support old-style user-defined functions, since depending
>  * on architecture and compiler, the return value of a function returning char
>  * or short may contain garbage when called as if it returned Datum.
> 
> Since we flushed support for V0 functions, the stated rationale doesn't
> apply anymore.  I wonder whether there is anything to be gained by
> changing DatumGetXXX and XXXGetDatum to be simple casts (as, if memory
> serves, they once were until we noticed the stated hazard).  Or, if
> there's still a reason to keep the masking steps in place, we'd better
> update this comment.

23a41573 did not do it rightly visibly, and 23b09e1 got it better, still
GET_1_BYTE() was getting used only because of V0 functions being used in
contrib/seg and because of the way MSVC 2015 handles boolean evaluation
as per thread [1].

In short, your argument for a switch to simple casts makes sense for me.

[1]: https://www.postgresql.org/message-id/E1atdPs-0005zu-Re@gemulon.postgresql.org
--
Michael