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

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

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns
Следующее
От: Elein
Дата:
Сообщение: Re: BUG #7730: intarray representation of empty arrays