From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Tender Wang <tndrwang(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Consistently use macro HeapTupleIsValid to check the validity of tuples in tablecmds.c |
Date: | 2025-04-10 12:37:36 |
Message-ID: | f6017e31-ea17-437b-bae0-37bee2683dd1@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09.04.25 16:23, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
>> Inconsistency is not good either though. I'm not sure it's worth the
>> churn, but I could get on board a patch to actually replace all
>> HeapTupleIsValid(tuple) calls with plain "tuple != NULL" checks. Keep
>> HeapTupleIsValid() just for compatibility, with a comment to discourage
>> using it.
>
> Would you then advocate for also removing macros such as OidIsValid()
> and PointerIsValid()? That gets into a *lot* of code churn, and
> subsequent back-patching pain. We had a discussion about that
> just recently IIRC, and decided not to go there.
I'd generally be in favor of getting rid of these. Many of these
*IsValid macros generally don't actually do anything useful on top of
plain C code, and they add a level of mystery and confusion. No one is
adding new ones like that, so over time, the coding styles diverge. And
they distract from macros that actually do something useful like
AllocSizeIsValid().
In terms of backpatching effort/risk, here are some simple statistics:
git log --oneline REL_13_0..REL_13_20 | wc -l
1920
git log --oneline -G OidIsValid REL_13_0..REL_13_20 | wc -l
25
git log --oneline -G PointerIsValid REL_13_0..REL_13_20 | wc -l
5
So from that it would appear to be a relatively very small problem.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2025-04-10 12:39:04 | Re: Some problems regarding the self-join elimination code |
Previous Message | jian he | 2025-04-10 12:37:16 | Re: speedup COPY TO for partitioned table. |