From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: safer node casting |
Date: | 2017-01-02 04:32:25 |
Message-ID: | CAFjFpRcqJtQ574QzVMSQogdDVu=A6PwfOshtWWmksUtzr-GhYg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Dec 31, 2016 at 11:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
>> I propose a macro castNode() that combines the assertion and the cast,
>> so this would become
>> RestrictInfo *rinfo = castNode(RestrictInfo, lfirst(lc));
>
+1. That would be wonderful.
> Seems like an OK idea, but I'm concerned by the implied multiple
> evaluations, particularly if you're going to apply this to function
> results --- as the above example does. I think you need to go the
> extra mile to make it single-evaluation. See newNode() for ideas.
>
+1.
In case the Assert fails, the debugger would halt at castNode macro
and a first time reader would be puzzled to see no assert there.
Obviously looking at the #define should clarify the confusion. But I
don't see how that can be avoided. I was thinking of using a function
castNodeFunc(), but it can't accomodate Assert with _type_. Will
calling this function as checkAndCastNode() help?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-01-02 04:47:47 | Re: rewrite HeapSatisfiesHOTAndKey |
Previous Message | Steve Singer | 2017-01-02 04:23:00 | Re: Logical Replication WIP |