Re: clarify equalTupleDescs()
Peter Eisentraut <peter@eisentraut.org>
From: Peter Eisentraut <peter@eisentraut.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-02-12T12:49:46Z
Lists: pgsql-hackers
Attachments
- v1-0001-Separate-equalRowTypes-from-equalTupleDescs.patch (text/plain) patch v1-0001
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.
Commits
-
Separate equalRowTypes() from equalTupleDescs()
- 20e58105badf 17.0 landed