Re: [HACKERS] taking stdbool.h into use

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>
Subject: Re: [HACKERS] taking stdbool.h into use
Date: 2018-01-11 23:40:05
Message-ID: 25211.1515714005@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> That leaves the uses in rowtypes.c. Those were introduced as a
> portability fix by commit 4cbb646334b. I'm curious why these are
> necessary. The Datums they operate come from heap_deform_tuple(), which
> gets them from fetchatt(), which does run all pass-by-value values
> through the very same GET_X_BYTES() macros (until now). I don't see
> where those dirty upper bits would be coming from.

I don't see it either. I think the actually useful parts of that patch
were to declare record_image_cmp's result correctly as int rather than
bool, and to cope with varlena fields of unequal size. Unfortunately
there seems to be no contemporaneous mailing list discussion, so
it's not clear what Kevin based this change on.

Want to try reverting the GET_X_BYTES() parts of it and see if the
buildfarm complains?

Note if that if we simplify the GetDatum macros, it's possible that
record_image_cmp would change behavior, since it might now see signed not
unsigned values depending on whether the casts do sign extension or not.
Not sure if that'd be a problem.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2018-01-12 00:12:33 Re: Doc tweak for huge_pages?
Previous Message Greg Stark 2018-01-11 23:23:11 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions