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

From: Marko Tiikkaja <marko(at)joh(dot)to>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns
Date: 2014-01-19 00:50:01
Message-ID: 52DB2139.20604@joh.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
bug_8870.patch text/plain 1.6 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message mlipchuk 2014-01-19 16:11:39 BUG #8880: no indication of value when exceeded maximum length
Previous Message Stephen Frost 2014-01-19 00:08:35 Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns