| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Mikhail Gribkov <youzhick(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Nicely exiting PG_TRY and PG_CATCH |
| Date: | 2022-10-07 21:19:03 |
| Message-ID: | 3353555.1665177543@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Mikhail Gribkov <youzhick(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2022-10-07 21:48:24 | Re: Adding Support for Copy callback functionality on COPY TO api |
| Previous Message | Israel Barth Rubio | 2022-10-07 20:54:46 | Re: Add support for DEFAULT specification in COPY FROM |