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

From Xing Guo
Subject Re: PL/Python: Fix return in the middle of PG_TRY() block.
Date
Msg-id CACpMh+Afa1KRJ6Of2LZivoaZsvR3QaLWPS2oLfzhDP7=iv6uBw@mail.gmail.com
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>)
List pgsql-hackers
On Mon, Jan 16, 2023 at 11:29 PM Tom Lane <tgl@sss.pgh.pa.us> 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.

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.

                        regards, tom lane

Thank you Tom,

Based on your comments, I've refactored my clang checker[1], now it can warn about the following patterns:
1. return statement in PG_TRY(). We've catched all of them in this thread.
2. continue statement in PG_TRY() *unless* it's in for/while/do-while statements.
3. break statement in PG_TRY() *unless* it's in for/while/do-while/switch statements.
4. goto statement in PG_TRY() *unless* the label it points to is in the same PG_TRY block.

Good news is that, there's no patterns (2, 3, 4) in Postgres source tree and we've catched all of the return statements in the PG_TRY block in this thread.


Best Regards,
Xing

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Doc: Rework contrib appendix -- informative titles, tweaked sentences
Next
From: Andrew Dunstan
Date:
Subject: Re: Extracting cross-version-upgrade knowledge from buildfarm client