Re: Removing another gen_node_support.pl special case

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Removing another gen_node_support.pl special case
Date: 2022-12-02 13:00:55
Message-ID: 5a1228ed-1c28-f029-fa90-f5c3d050e785@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29.11.22 22:34, Tom Lane wrote:
> I wrote:
>> I notice that EquivalenceClass is already marked as no_copy_equal,
>> which means that gen_node_support.pl can know that emitting a
>> recursive node-copy or node-compare request is a bad idea. What
>> do you think of using the patch as it stands, plus a cross-check
>> that we don't emit COPY_NODE_FIELD or COMPARE_NODE_FIELD if the
>> target node type is no_copy or no_equal?
>
> Concretely, it seems like something like the attached could be
> useful, independently of the other change.

Yes, right now you can easily declare things that don't make sense.
Cross-checks like these look useful.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2022-12-02 13:16:07 Re: Missing MaterialPath support in reparameterize_path_by_child
Previous Message Ronan Dunklau 2022-12-02 12:58:27 Re: Fix gin index cost estimation