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