Re: BUG #8870: PL/PgSQL, SELECT .. INTO and the number of result columns
Вложения
В списке pgsql-bugs по дате отправления:
| От | 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
|
| Список | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера