clarify equalTupleDescs()

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема clarify equalTupleDescs()
Дата
Msg-id f656d6d9-6660-4518-a006-2f65cafbebd1@eisentraut.org
обсуждение исходный текст
Ответы Re: clarify equalTupleDescs()  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: clarify equalTupleDescs()  (jian he <jian.universality@gmail.com>)
Список pgsql-hackers
In a recent patch thread it was discussed[0] which fields should be 
compared by equalTupleDescs() and whether it is ok to remove a field 
from tuple descriptors and how that should affect their equality 
(attstattarget in that case).

After analyzing all the callers, I have noticed that there are two 
classes of callers of equalTupleDescs():

The first want to compare what I call row-type equality, which means 
they want to check specifically for equal number of attributes, and the 
same attribute names, types, and typmods for each attribute.  Most 
callers actually want that behavior.  The remaining callers just want to 
compare the tuple descriptors as they are, they don't care why the 
fields are in there, they just want to compare all of them.

In the attached patch, I add a new function equalRowTypes() that is 
effectively a subset of equalTupleDescs() and switch most callers to that.

The purpose of this patch is to make the semantics less uncertain. 
Questions like the one in [0] about attstattarget now have a clear 
answer for both functions.  I think this would be useful to have, as we 
are thinking about more changes in pg_attribute and tuple descriptors.


[0]: 
https://www.postgresql.org/message-id/202401101316.k4s3fomwjx52@alvherre.pgsql
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Memory consumed by paths during partitionwise join planning
Следующее
От: Alexander Lakhin
Дата:
Сообщение: Re: Race condition in FetchTableStates() breaks synchronization of subscription tables