I wrote:
> I think the issue basically arises from this concern in exec_move_row:
> * NOTE: this code used to demand row->nfields ==
> * HeapTupleHeaderGetNatts(tup->t_data), but that's wrong. The tuple
> * might have more fields than we expected if it's from an
> * inheritance-child table of the current table, or it might have fewer if
> * the table has had columns added by ALTER TABLE.
BTW, this comment is very old, dating to commit 8bb3c8fe5, which was
in response to
https://www.postgresql.org/message-id/flat/200104300537.f3U5brK62902%40hub.org
Looking at it again now, I wonder whether I didn't make the wrong choice
about how to fix the problem. The above concerns seem valid so far as the
physical number of fields in the tuple go, but they do not apply to the
tupdesc that comes with it. So arguably the real bug was using the
physical tuple rather than the tupdesc to drive the conversion, which is
something we got away from later anyway when we added dropped-column
support. Perhaps it'd be reasonable to throw an error if the number of
non-dropped columns in the source and destination tupdescs don't match,
even for the composite-type case.
The specific issue mentioned in the above bug report is gone anyway: if I
try that test case now, I don't see any tuples with extra columns arriving
at exec_move_row, because we insert a ConvertRowtypeExpr node to convert
the rows of the child table to the parent rowtype. But I'm not quite
prepared to assume that such cases can't arise through other examples.
Now, I do not think we can remove the facility for doing data type
conversion on the fields; undoubtedly there are people relying on being
able to SELECT INTO a numeric variable from an integer source column, for
example. So maybe being lax about the number of columns is a sensible
thing to go along with that. But it sure seems like a foot-gun.
regards, tom lane