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

From Pavel Stehule
Subject Re: plpgsql plugin - stmt_beg/end is not called for top level blockof statements
Date
Msg-id CAFj8pRBAj-9aBSsGQpQ9vb2VB=x4rqVL2=pdTqizUjSUyhHW0A@mail.gmail.com
Whole thread Raw
In response to Re: plpgsql plugin - stmt_beg/end is not called for top level blockof statements  (Michael Paquier <michael@paquier.xyz>)
Responses Re: plpgsql plugin - stmt_beg/end is not called for top level blockof statements
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Control your disk usage in PG: Introduction to Disk QuotaExtension
Next
From: Tatsuro Yamada
Date:
Subject: Re: Tab completion for ALTER INDEX|TABLE ALTER COLUMN SET STATISTICS