Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns |
| Дата | |
| Msg-id | 25794.1390089578@sss.pgh.pa.us обсуждение |
| Ответ на | BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns (marko@joh.to) |
| Ответы |
Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of
result columns
Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns |
| Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: