Re: Removing another gen_node_support.pl special case
| От | Peter Eisentraut |
|---|---|
| Тема | Re: Removing another gen_node_support.pl special case |
| Дата | |
| Msg-id | 022d86ba-0d31-5b62-1276-9d9137f72c51@enterprisedb.com обсуждение исходный текст |
| Ответ на | Removing another gen_node_support.pl special case (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Removing another gen_node_support.pl special case
|
| Список | 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 по дате отправления: