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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql plugin - stmt_beg/end is not called for top level block of statements
Date: 2018-12-26 06:02:04
Message-ID: CAFj8pRBAj-9aBSsGQpQ9vb2VB=x4rqVL2=pdTqizUjSUyhHW0A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

st 26. 12. 2018 v 6:09 odesílatel Michael Paquier <michael(at)paquier(dot)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
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuro Yamada 2018-12-26 06:07:33 Re: Tab completion for ALTER INDEX|TABLE ALTER COLUMN SET STATISTICS
Previous Message Michael Paquier 2018-12-26 05:56:47 Re: Control your disk usage in PG: Introduction to Disk Quota Extension