Re: PL/Python: Fix return in the middle of PG_TRY() block. - Mailing list pgsql-hackers

From Andres Freund
Subject Re: PL/Python: Fix return in the middle of PG_TRY() block.
Date
Msg-id 20230120010711.jpqbaelpgmuvt2vq@awork3.anarazel.de
Whole thread Raw
In response to Re: PL/Python: Fix return in the middle of PG_TRY() block.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PL/Python: Fix return in the middle of PG_TRY() block.
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Unicode grapheme clusters
Next
From: Jeff Davis
Date:
Subject: Re: Non-superuser subscription owners