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

Josh Berkus <josh@agliodbs.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