|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>|
|Cc:||Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>|
|Subject:||Re: [HACKERS] taking stdbool.h into use|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> So, looking at 0001 now... Shouldn't there be a DatumGetBool8(), with
> the existing DatumGetBool() which should depend on the size of bool? I
> can see that all the catalogs are correctly updated with bool8 in the
Surely bool and bool8 should have identical Datum representations,
so I'm not sure they need different DatumGet/GetDatum macros.
Although this opens up another point: just above those macros,
* 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.
regards, tom lane
|Next Message||Tom Lane||2017-12-30 15:45:19||Re: TAP test module - PostgresClient|
|Previous Message||Andrew Dunstan||2017-12-30 15:04:41||Re: TAP test module - PostgresClient|