Re: plpgsql plugin - stmt_beg/end is not called for top level blockof statements

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: plpgsql plugin - stmt_beg/end is not called for top level blockof statements
Дата
Msg-id CAFj8pRBAj-9aBSsGQpQ9vb2VB=x4rqVL2=pdTqizUjSUyhHW0A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: plpgsql plugin - stmt_beg/end is not called for top level blockof statements  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: plpgsql plugin - stmt_beg/end is not called for top level blockof statements  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers


st 26. 12. 2018 v 6:09 odesílatel Michael Paquier <michael@paquier.xyz> napsal:
On Wed, Dec 19, 2018 at 07:04:50AM +0100, Pavel Stehule wrote:
> I can imagine some tracking extension, that will do some
> initializations on plpgsql_stmt_block statement hook - but the most
> important will not be called ever.

I was just studying this stuff and reviewing this patch with fresh
eyes, and it seems to me that it is actually incorrect.  This changes
the execution logic so as stmt_beg and stmt_end are called
additionally each time a function, a trigger or an event trigger is
executed.  If one looks closely at the code, he/she could notice that
func_beg and func_end are already present as hook points to watch what
is happening in the execution, as these are here to give entry points
for execution functions, so it seems to me that we don't need extra
watch calls as proposed, because there is already everything needed,
and that the current points are correct.

The design about this feature has not clean borders - I see a problem with func_beg and func_end because these handlers should to share some logic with stmt_beg, stmt_end when handler for stmt_block is not empty.

More the some behave can be surprise for developer - example - if use handler for smt_beg

then for code

$$
BEGIN
  RETURN x;
END;
$$

is called only once - what is expected;

but for code

$$
BEGIN
  BEGIN
    RETURN x;
  END;
END
$$

is called two times, what is not expected, if you don't know some about this inconsistency.

So it is reason, why I don't think so current behave is correct. On second hand, the impact is very small - only few extensions uses plpgsql plugin API, and workaround is not hard. So I can live with current state if nobody see this issue (sure - it is minor issue).

Regards

Pavel
 
--
Michael

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Control your disk usage in PG: Introduction to Disk QuotaExtension
Следующее
От: Tatsuro Yamada
Дата:
Сообщение: Re: Tab completion for ALTER INDEX|TABLE ALTER COLUMN SET STATISTICS