Re: Removing another gen_node_support.pl special case

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Removing another gen_node_support.pl special case
Дата
Msg-id 5a1228ed-1c28-f029-fa90-f5c3d050e785@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Removing another gen_node_support.pl special case  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Removing another gen_node_support.pl special case  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Ronan Dunklau
Дата:
Сообщение: Re: Fix gin index cost estimation
Следующее
От: Richard Guo
Дата:
Сообщение: Re: Missing MaterialPath support in reparameterize_path_by_child