Re: Nicely exiting PG_TRY and PG_CATCH
| От | Mikhail Gribkov |
|---|---|
| Тема | Re: Nicely exiting PG_TRY and PG_CATCH |
| Дата | |
| Msg-id | CAMEv5_sUmv6_Zm3-JBR7VTXH-uxJE+GF=p+0EY4=LZD8hsO6FQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Nicely exiting PG_TRY and PG_CATCH (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
> Yeah, you can't return or goto out of the PG_TRY part.
So this is a problem if the check would ever work.
(Sorry for such a delayed answer.)
Then we need to fix it. Attached is a minimal patch, which changes nothing except for correct PG_TRY exiting.
Isn't it better this way?
CCing to Peter Eisentraut, whose patch originally introduced these returns.
Peter, will such a patch work somehow against your initial idea?
--
On Sat, Oct 8, 2022 at 12:19 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Mikhail Gribkov <youzhick@gmail.com> writes:
> Usually it's not a good idea to exit PG_TRY() block via return statement.
> Otherwise it would leave PG_exception_stack global variable in a wrong
> state and next ereport() will jump to some junk address.
Yeah, you can't return or goto out of the PG_TRY part.
> Another suspicious case is PG_CATCH block in jsonb_plpython.c:
This should be OK. The PG_CATCH and PG_FINALLY macros are set up so that
we've fully restored that state *before* we execute any of the
error-handling code. It would be basically impossible to have a guarantee
that CATCH blocks never throw errors; they'd be so restricted as to be
near useless, like signal handlers.
regards, tom lane
Вложения
В списке pgsql-hackers по дате отправления: