marko@joh.to writes:
> =# create function f() returns void as
> -# $$declare
> $# f1 int;
> $# begin
> $# select 1, 2 into f1;
> $# end
> $# $$ language plpgsql;
> CREATE FUNCTION
> =# select f();
> f
> ---
> (1 row)
> This seems to have been broken by commit
> 8bb3c8fe5413103c30ba8d1bcb3a1f8e46bddf3d.
Did you really test against a pre-2001 plpgsql?
The comments in that commit are correct as far as they go: we *must* be
willing to accept tuples with more or fewer attributes than the row has
fields, or unpleasant things will happen with code that is correct on
its face, if the table it's fetching from has inheritance children
and/or has been subject to ALTER TABLE.
ISTM what you're really asking for is a compile time (not run-time) check
that the number of INTO targets matches the nominal number of output
columns of the query. Not sure how difficult that is, but it'd be more
likely to be successful than messing with the run-time behavior in
exec_move_row.
regards, tom lane
