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.
>
> 2. The attributes in a TupleDesc will (always?) have consecutive attnum
> corresponding to their positions in the TupleDesc (and therefore
> redundant). A query, say, that projects out a subset of columns
> from a relation will not have a result TupleDesc with attributes
> still bearing their original attrelid and attnum; they'll have
> attrelid zero and consecutive renumbered attnum.
>
> Something like SendRowDescriptionCols_3 that wants the original table
> and attnum has to reconstruct them from the targetlist if available,
>
> Have I mistaken any of that?
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.
In building a corresponding tuple, any dropped attribute should
have its null flag set.
Is it simple to say under what circumstances a TupleDesc possibly
with dropped members could be encountered, and under what other
circumstances one would only encounter 'cleaned up' TupleDescs with
no dropped attributes, and contiguous numbers for the real ones?
Regards,
-Chap
