Re: PL/Python: Fix return in the middle of PG_TRY() block.
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Xing Guo <higuoxing@gmail.com>, Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers@postgresql.org
Date: 2023-01-20T01:07:11Z
Lists: pgsql-hackers
Hi, On 2023-01-16 10:29:03 -0500, Tom Lane wrote: > Xing Guo <higuoxing@gmail.com> writes: > > Are there any unsafe codes in pltcl.c? The return statement is in the > > PG_CATCH() block, I think the exception stack has been recovered in > > PG_CATCH block so the return statement in PG_CATCH block should be ok? > > Yes, the stack has already been unwound at the start of a PG_CATCH > (or PG_FINALLY) block, so there is no reason to avoid returning > out of those. It's probably true for PG_CATCH, but for PG_FINALLY? Won't returning lead us to miss rethrowing the error? I guess you can argue that's desired, but then why would one use PG_FINALLY? I'm somewhat dubious about allowing to return inside PG_CATCH, even if it's safe today. > In principle you could also mess things up with a "continue", "break", > or "goto" leading out of PG_TRY. That's probably far less likely > than "return", but I wonder whether Andres' compiler hack will > catch that. I haven't tested it, but it should - it basically traces every path and sees whether there's any way the "capability" isn't released. To the point that it's very annoying in other contexts, because it doesn't deal well with conditional lock acquisition/releases. Greetings, Andres Freund
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Move return statements out of PG_TRY blocks.
- 0af386b0f4b8 11.20 landed
- 24964394a972 12.15 landed
- 800531846ef7 13.11 landed
- 52c9cf3239b8 14.8 landed
- 825ebc9848fd 15.3 landed
- 57d0051706b8 16.0 landed