Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns - Mailing list pgsql-bugs

From Marko Tiikkaja
Subject Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns
Date
Msg-id 52DB2139.20604@joh.to
Whole thread Raw
In response to Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns  (Marko Tiikkaja <marko@joh.to>)
List pgsql-bugs
On 1/19/14, 12:59 AM, Tom Lane wrote:
>> This seems to have been broken by commit
>> 8bb3c8fe5413103c30ba8d1bcb3a1f8e46bddf3d.
>
> Did you really test against a pre-2001 plpgsql?

No, I can't compile it.  It just *looks* like the behaviour was broken
by that commit.  Sorry for the confusion.

> 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.

Please correct me if I'm wrong, but as far as I can tell we can't do
that check at compile time because we don't do parse analysis.  And
making that happen every time CREATE FUNCTION is called..  I don't see
that happening.

But making this check at run time doesn't seem too hard.  How broken
does the attached look?  It passes all the existing regression tests, at
least..


Regards,
Marko Tiikkaja

Attachment

pgsql-bugs by date:

Previous
From: Stephen Frost
Date:
Subject: Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns
Next
From: Elein
Date:
Subject: Re: BUG #7730: intarray representation of empty arrays