Re: clarify equalTupleDescs()
От | Peter Eisentraut |
---|---|
Тема | Re: clarify equalTupleDescs() |
Дата | |
Msg-id | 0054cd47-da6b-4fde-924e-69512630e6a2@eisentraut.org обсуждение исходный текст |
Ответ на | Re: clarify equalTupleDescs() (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: clarify equalTupleDescs()
Re: clarify equalTupleDescs() |
Список | pgsql-hackers |
On 06.02.24 16:14, Tom Lane wrote: > Peter Eisentraut <peter@eisentraut.org> writes: >> 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. > > Should compare attcollation too, no? > > +1 for the general idea, but it seems like "row type equality" > might still be a slightly fuzzy concept. I did another pass across the callers to check what pg_attribute fields might be relevant. Collation definitely needs to be added, certainly for plancache.c, maybe for typcache.c, the other callers don't care. Record types can have attisdropped fields, so it's probably good to check those. I'm suspicious about attndims. Maybe one could create a test case where record types differ only in that. Support for attndims throughout the system is weak, but maybe there is something to check there. On a conceptual level, I figured pg_attribute rows can be divided up into three categories: 1. "row type" stuff: attname, atttypid, atttypmod, attndims, attisdropped, attcollation 2. physical layout stuff: attlen, attcacheoff, attbyval, attalign 3. table metadata stuff (everything else) It's not perfect, and sometimes it's not clear whether these categories inform the implementation or the other way around, but I think it helps conceptualize it.
Вложения
В списке pgsql-hackers по дате отправления: