Re: PL/Python: Fix return in the middle of PG_TRY() block.

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Xing Guo <higuoxing(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PL/Python: Fix return in the middle of PG_TRY() block.
Date: 2023-01-20 01:07:11
Message-ID: 20230120010711.jpqbaelpgmuvt2vq@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2023-01-16 10:29:03 -0500, Tom Lane wrote:
> Xing Guo <higuoxing(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2023-01-20 01:16:20 Re: Non-superuser subscription owners
Previous Message Tom Lane 2023-01-20 00:53:43 Re: Unicode grapheme clusters