Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: marko(at)joh(dot)to
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns
Date: 2014-01-18 23:59:38
Message-ID: 25794.1390089578@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

marko(at)joh(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Stephen Frost 2014-01-19 00:08:35 Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns
Previous Message Stephen Frost 2014-01-18 23:37:43 Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns