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?
Thanks,
-Chap