Re: checking my understanding of TupleDesc

Chapman Flack <chap(at)anastigmatix(dot)net> writes:
> On 09/29/19 20:13, Chapman Flack wrote:
>> From looking around the code, I've made these tentative observations
>> about TupleDescs:
>>
>> 1. If the TupleDesc was obtained straight from the relcache for some
>> relation, then all of its attributes should have nonzero attrelid
>> identifying that relation, but in (every? nearly every?) other case,
>> the attributes found in a TupleDesc will have a dummy attrelid of zero.

I'm not sure about every vs. nearly every, but otherwise this seems
accurate. Generally attrelid is meaningful in a pg_attribute catalog
entry, but not in TupleDescs in memory. It appears valid in relcache
entry tupdescs only because they are built straight from pg_attribute.

>> 2. The attributes in a TupleDesc will (always?) have consecutive attnum
>> corresponding to their positions in the TupleDesc (and therefore
>> redundant).

Correct.

> And one more:

> 3. One could encounter a TupleDesc with one or more 'attisdropped'
> attributes, which do have their original attnums (corresponding
> to their positions in the TupleDesc and therefore redundant),
> so the attnums of nondropped attributes may be discontiguous.

Right.

> Is it simple to say under what circumstances a TupleDesc possibly
> with dropped members could be encountered,

Any tupdesc that's describing the rowtype of a table with dropped columns
would look like that.

> and under what other
> circumstances one would only encounter 'cleaned up' TupleDescs with
> no dropped attributes, and contiguous numbers for the real ones?

I don't believe we ever include dropped columns in a projection result,
so generally speaking, the output of a query plan node wouldn't have them.

There's a semi-exception, which is that the planner might decide that we
can skip a projection step for the output of a table scan node, in which
case dropped columns would be included in its output. But that would only
be true if there are upper plan nodes that are doing some projections of
their own. The final query output will definitely not have them.

regards, tom lane