Peter Eisentraut <pe...@eisentraut.org> writes:
> On 06.02.24 16:14, Tom Lane wrote:
>> +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.
+1
> Record types can have attisdropped fields, so it's probably good to
> check those.
Yeah, good idea. (In most cases the attname comparison would catch
that, but we shouldn't rely on it.) In a perfect world maybe a
dropped column should be invisible to this comparison, but we're
a very long way from being able to treat it that way.
> 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.
There was a discussion last year[1] about removing attndims
altogether, which still seems to me like possibly a good idea.
So I doubt we want to consider it as a core semantic field.
> 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
I recall some discussion about taking attcacheoff out of this data
structure too ...
> 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.
Sure.
regards, tom lane
[1]
https://www.postgresql.org/message-id/flat/ZD%2B14YZ4IUue8Rhi%40gendo.asyd.net
