Re: clarify equalTupleDescs()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: clarify equalTupleDescs()
Date: 2024-02-12 15:59:58
Message-ID: 2233044.1707753598@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2024-02-12 16:08:40 Re: backend *.c #include cleanup (IWYU)
Previous Message Nathan Bossart 2024-02-12 15:57:15 Re: glibc qsort() vulnerability