Re: plpgsq_plugin's stmt_end() is not called when an error is caught
От | Pavel Stehule |
---|---|
Тема | Re: plpgsq_plugin's stmt_end() is not called when an error is caught |
Дата | |
Msg-id | CAFj8pRDoZnaszD3Jd=M-6Nxz2h2PqqAv0iLDBrm1NnJQzs3mGg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: plpgsq_plugin's stmt_end() is not called when an error is caught (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: plpgsq_plugin's stmt_end() is not called when an error is caught
|
Список | pgsql-hackers |
čt 15. 12. 2022 v 8:53 odesílatel Kyotaro Horiguchi <horikyota.ntt@gmail.com> napsal:
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.
What we (pg_hint_plan people) want is any means to know that the
top-level function is exited, to reset function nest level. It would
be simpler than calling end callback at every nest level.
I found some solution based by using fmgr hook
regards
Pavel
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: