Gregory Stark <stark@enterprisedb.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> * tupdesc has fewer columns than the tuple does. I think this can
>> happen in certain inheritance cases --- we might be inspecting a child
>> tuple using a parent's tupdesc.
> There are some comments in the source about cases like this but I've never
> understood how it can happen. Children are supposed to have a superset of the
> parent's columns. Does it depend on the parent having had dropped columns but
> not the child? But then wouldn't the Append node have had to do some magic to
> map the columns correctly meaning you wouldn't be looking at the physical
> tuple any more?
Sorry, I missed this part of your response. I dug around a bit and
found that the comments suggesting this can happen date back to 7.1
days, and arose from situations wherein a function declared to take
a table rowtype "foo" gets invoked on a tuple from an inheritance child
"foo_child".
Now, while ignoring added columns in the child is certainly *necessary*
in this case, it is not *sufficient*. The child's columns corresponding
to the parent's might have different column numbers. So really you need
to map the child's tuples through a conversion operation. We do have
the infrastructure for that now, which we did not have in 7.1 --- look
at ConvertRowtypeExpr and associated code.
Bottom line is that the concern about tupdesc natts < tuple natts might
be obsolete. Nonetheless, it's wrong or at least uselessly fragile
for the code to be assuming that the case cannot happen; and if it were
to happen, the correct limit to use is the tupdesc's not the tuple's.
The tupdesc always defines what the calling code is expecting to see.
regards, tom lane