Re: cast result of copyNode() - Mailing list pgsql-hackers

From David Steele
Subject Re: cast result of copyNode()
Date
Msg-id 187036f4-80e1-8163-4ee3-92ba9069140b@pgmasters.net
Whole thread Raw
In response to Re: [HACKERS] cast result of copyNode()  (Mark Dilger <hornschnorter@gmail.com>)
List pgsql-hackers
On 3/21/17 6:52 PM, Mark Dilger wrote:
>
>> On Mar 21, 2017, at 2:13 PM, David Steele <david@pgmasters.net> wrote:
>>
>> Hi Mark,
>>
>> On 3/9/17 3:34 PM, Peter Eisentraut wrote:
>>> On 3/7/17 18:27, Mark Dilger wrote:
>>>> You appear to be using a #define macro to wrap a function of the same name
>>>> with the code:
>>>>
>>>> #define copyObject(obj) ((typeof(obj)) copyObject(obj))
>>>
>>> Yeah, that's a bit silly.  Here is an updated version that changes that.
>>
>> Do you know when you'll have a chance to take a look at the updated patch?
>
> The patch applies cleanly, compiles, and passes all the regression tests
> for me on my laptop.  Peter appears to have renamed the function copyObject
> as copyObjectImpl, which struct me as odd when I first saw it, but I don't have
> a better name in mind, so that seems ok.
>
> If the purpose of this patch is to avoid casting so many things down to (Node *),
> perhaps some additional work along the lines of the patch I'm attaching are
> appropriate.  (This patch applies on top Peter's v2 patch).  The idea being to
> keep objects as (Expr *) where appropriate, rather than casting through (Node *)
> quite so much.
>
> I'm not certain that this is (a) merely a bad idea, (b) a different idea than what
> Peter is proposing, and as such should be submitted independently, or
> (c) something that aught to be included in Peter's patch prior to commit.
> I only applied this idea to one file, and maybe not completely in that file, because
> I'd like feedback before going any further along these lines.

I have marked this "Waiting on Author" pending Peter's input.

-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WIP: Faster Expression Processing v4
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench - allow to store select results intovariables