On 06/21/2017 06:06 AM, Pierre Ducroquet wrote:
Please reply to list also.
Ccing list.
On Wednesday, June 21, 2017 5:49:29 AM CEST you wrote:
On 06/21/2017 04:28 AM, Pierre Ducroquet wrote:
Hi
I found a workaround using event triggers to rewrite every function when
an
alter occurs on such a table, but this seems… odd to me. I don't think we
are doing anything very complicated here, so I'm surprised that nothing
has been done yet to fix that issue.
https://www.postgresql.org/docs/9.6/static/plpgsql-statements.html#PLPGSQL-S
TATEMENTS-EXECUTING-DYN
Did I miss something obvious, or should I report that as a bug and start
digging PostgreSQL code ?
https://www.postgresql.org/docs/9.6/static/plpgsql-implementation.html#PLPGS
QL-PLAN-CACHING
Thanks
Hi Adrian
I know this caching behavior is well-known and documented, and a disturbed way
of writing triggers will fix it (prefixing every statement with EXECUTE would
make for even uglier procedures), but still it seems counter-intuitive and
could deserve being called a bug, or a serious restriction.
I was very surprised to be hit by this so easily. Also, even after a backend
was hit by a failure, it kept running the wrong plan until I forced a new
function version. Hence my questioning, is there more than just «plpgsql cache
plans» in that issue…
If there is nothing else, then I'll start digging the code…
I don't know, which is why I am returning this to list.
Pierre
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
