Re: Bug in prepared statement cache invalidation?

On 01.05.2017 16:09, Robert Haas wrote:
>
> This problem has been discussed before but nobody's done anything
> about it. The problem is a bit tricky because the core system doesn't
> know anything about the function caches maintained by individual PLs.
> I suppose ideally there'd be a way for a PL to say "if the definition
> of X changes, please tell me to recompile function Y". That probably
> wouldn't be perfect because the PL might not be able to figure out
> everything on which they actually depend; that might be
> Turing-complete in some cases. But even a partial solution would
> probably be welcomed by users.
>

Thank you for explanation.
May be I am missing something, but what is the problem with keeping
dependencies for PL functions?
As you wrote, PL can inform core that functions depends on some set of
relations/types/functions and so has to be recompiled if some of them
are changed.
It is not necessary to build closure of dependency graph - instead of it
cascade invalidation can be used.
So it is not clear to me where you see here the source of complexity and
why this task may be "Turing-complete in some cases"?

The problem can be with overloaded functions and PL languages without
static type checking.
In this case resolving has to be performed at runtime during function
evaluation. But there should be no such problem with PLpgSQL.

But definitely introducing such dependency tracking mechanism for PL
will require a lot of changes, in all PL implementations. Looks like no
easy fix is possible here.
I am not sure how critical is this problem. Definitely it rarely
happens, but lack of normal workarounds (restart backend, recreate
function?) seems to be disappointing.

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company