Re: Different results in a loop with RECORD vs ROWTYPE...

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> I believe that we should raise an exception if the SELECT statement does not
> match the ROWTYPE, though of course we'd have to provide a
> backward-compatible GUC in case anyone is counting on the current behavior.

Digging in the code, I see this comment in exec_move_row:

* NOTE: this code used to demand row->nfields == tup->t_data->t_natts,
* 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. Ignore extra columns and assume NULL for missing
* columns, the same as heap_getattr would do.

So blindly restoring the column-count check will break things. I think
that the above considerations only apply to one of the call sites of
exec_move_row, so we could make the other ones apply the check, but
clearly it's a little more ticklish than one would think.

> If you're still interested, I will consult my PL/SQL bible this afternoon to
> see what Oracle 8i does in this case.

Since plpgsql is generally supposed to be a slavish imitation of Oracle,
it would be good to know what they do...

regards, tom lane