Re: Error message with plpgsql CONTINUE
От | Tom Lane |
---|---|
Тема | Re: Error message with plpgsql CONTINUE |
Дата | |
Msg-id | 21320.1440202918@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Error message with plpgsql CONTINUE (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: Error message with plpgsql CONTINUE
Re: Error message with plpgsql CONTINUE |
Список | pgsql-hackers |
Jim Nasby <Jim.Nasby@BlueTreble.com> writes: > On 8/17/15 9:48 AM, Tom Lane wrote: >>> I'm inclined to think that if we wanted to make this better, the way to >>> improve it would be to detect the error*at compile time*, and get rid of >>> this hack in plpgsql_exec_function altogether. > Here's a patch that does that. This also made it possible to check for > CONTINUE/EXIT being used outside a loop during parsing, so I changed > that as well and removed those checks from pl_exec.c. Applied with some fixes. The major oversight was that EXIT does *not* have the same rules as CONTINUE, as is clearly documented (though in your defense, there was no regression test verifying the behavior ... there is now). > I refactored the 3 > places that were doing the check into exec_stmt_block(), renaming the > original function exec_stmt_block_rc for the one place that still needs > the return code. I did not like that part. Simpler and less code churn to just take out the now-unnecessary outer-level tests. Also, your way lost the separate error texts for "control reached end of function" and "control reached end of trigger procedure", which while maybe not very important was not an agreed-to change. regards, tom lane
В списке pgsql-hackers по дате отправления: