Re: clarify equalTupleDescs()

Peter Eisentraut <peter(at)eisentraut(dot)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