>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
