On Thu, Dec 15, 2022 at 4:53 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > At Thu, 15 Dec 2022 08:41:21 +0100, Pavel Stehule <pavel.stehule@gmail.com> wrote in > > čt 15. 12. 2022 v 8:25 odesílatel Masahiko Sawada <sawada.mshk@gmail.com> > > napsal: > > > Is this a bug in plpgsql? > > > > > > > I think it is by design. There is not any callback that is called after an > > exception. > > > > It is true, so some callbacks on statement error and function's error can > > be nice. It can help me to implement profilers, or tracers more simply and > > more robustly. > > > > But I am not sure about performance impacts. This is on a critical path. > > I didn't searched for, but I guess all of the end-side callback of all > begin-end type callbacks are not called on exception. Additional > PG_TRY level wouldn't be acceptable for performance reasons.
I don't think we need additional PG_TRY() for that since exec_stmts() is already called in PG_TRY() if there is an exception block. I meant to call stmt_end() in PG_CATCH() in exec_stmt_block() (i.e. only when an error is caught by the exception block). Currently, if an error is caught, we call stmt_begin() and stmt_end() for statements executed inside the exception block but call only stmt_begin() for the statement that raised an error.
PG_TRY is used only for STMT_BLOCK, other statements don't use PG_TRY.
I have no idea about possible performance impacts, I never tested it. Personally, I like the possibility of having some error callback function. Maybe PG_TRY can be used, only when this callback is used. So there will not be any impact on performance without some extensions that use it. Unfortunately, there are two functions necessary. Some exceptions can be raised after the last statement before the function ends. Changing behaviour of stmt_end or func_end can be problematic, because after an exception a lot of internal API is not available, and you should know, so this is that situation. Now anybody knows so at stmt_end function, the code is not after an exception.
But it can be not too easy, because there can be more chained extensions that use dbg API - like PL profiler, PL debugger and plpgsql_check - and maybe others.
