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 022d86ba-0d31-5b62-1276-9d9137f72c51@enterprisedb.com
Whole thread Raw
In response to 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 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 best off
> dropping in favor of explicit annotations on affected fields.
> Hence, I propose the attached.  This results in zero change in
> the generated copy/equal code.

I suppose the question is whether this behavior is something that is a 
property of the EquivalenceClass type as such or something that is 
specific to each individual field.




pgsql-hackers by date:

Previous
From: Maxim Orlov
Date:
Subject: Re: Add 64-bit XIDs into PostgreSQL 15
Next
From: gkokolatos@pm.me
Date:
Subject: Re: Add LZ4 compression in pg_dump