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 по дате отправления: