Re: [HACKERS] safer node casting - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: [HACKERS] safer node casting
Date
Msg-id CAFjFpRcqJtQ574QzVMSQogdDVu=A6PwfOshtWWmksUtzr-GhYg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] safer node casting  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Dec 31, 2016 at 11:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Steve Singer
Date:
Subject: Re: [HACKERS] Logical Replication WIP
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] rewrite HeapSatisfiesHOTAndKey