Peter Eisentraut writes:
> On 29.11.22 22:34, Tom Lane wrote:
>> 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.
Checking my
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
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
Peter Eisentraut writes:
> On 27.11.22 02:39, Tom Lane wrote:
>> I got confused about how we were managing EquivalenceClass pointers
>> in the copy/equal infrastructure, and it took me awhile to remember
>> that the reason it works is that gen_node_support.pl has hard-wired
>> knowledge about
On 27.11.22 02:39, Tom Lane wrote:
I got confused about how we were managing EquivalenceClass pointers
in the copy/equal infrastructure, and it took me awhile to remember
that the reason it works is that gen_node_support.pl has hard-wired
knowledge about that. I think that's something we'd be
I got confused about how we were managing EquivalenceClass pointers
in the copy/equal infrastructure, and it took me awhile to remember
that the reason it works is that gen_node_support.pl has hard-wired
knowledge about that. I think that's something we'd be best off
dropping in favor of explicit
