On 19.08.2020 21:50, Pavel Stehule wrote:
> Hi
>
> st 19. 8. 2020 v 19:22 odesílatel Konstantin Knizhnik
> <k(dot)knizhnik(at)postgrespro(dot)ru <mailto:k(dot)knizhnik(at)postgrespro(dot)ru>> napsal:
>
> Hi hackers,
>
> More than month ago I have sent bug report to pgsql-bugs:
>
> https://www.postgresql.org/message-id/flat/5d335911-fb25-60cd-4aa7-a5bd0954aea0%40postgrespro.ru
>
> with the proposed patch but have not received any response.
>
> I wonder if there is some other way to fix this issue and does
> somebody
> working on it.
> While the added check itself is trivial (just one line) the total
> patch
> is not so small because I have added walker for
> plpgsql statements tree. It is not strictly needed in this case
> (it is
> possible to find some other way to determine that stored procedure
> contains transaction control statements), but I hope such walker
> may be
> useful in other cases.
>
> In any case, I will be glad to receive any response,
> because this problem was reported by one of our customers and we
> need to
> provide some fix.
> It is better to include it in vanilla, rather than in our pgpro-ee
> fork.
>
> If it is desirable, I can add this patch to commitfest.
>
>
>
> I don't like this design. It is not effective to repeat the walker for
> every execution. Introducing a walker just for this case looks like
> overengineering.
> Personally I am not sure if a walker for plpgsql is a good idea (I
> thought about it more times, when I wrote plpgsql_check). But anyway -
> there should be good reason for introducing the walker and clean use case.
>
> If you want to introduce stmt walker, then it should be a separate
> patch with some benefit on plpgsql environment length.
>
If you think that plpgsql statement walker is not needed, then I do not
insist.
Are you going to commit your version of the patch?