Re: Removing another gen_node_support.pl special case - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Removing another gen_node_support.pl special case
Date
Msg-id 5a1228ed-1c28-f029-fa90-f5c3d050e785@enterprisedb.com
Whole thread Raw
In response to Re: Removing another gen_node_support.pl special case  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Removing another gen_node_support.pl special case
List 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.




pgsql-hackers by date:

Previous
From: Ronan Dunklau
Date:
Subject: Re: Fix gin index cost estimation
Next
From: Richard Guo
Date:
Subject: Re: Missing MaterialPath support in reparameterize_path_by_child