On Tue, May 2, 2017 at 6:07 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: > 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"?
Well, if the user's using PL/python or similar, they can do an arbitrary computation and use the result as a table name. There's no way for the core system to know what table name that will end up referencing. > 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. Yeah, maybe. But what if the PL/pgsql function calls some other function that creates a table, and then tries to access that table from the original function, or something like that? There are weird cases, I think, where even in PL/pgSQL it's not easy to figure out for sure what the dependencies are. > 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. The problem goes away if you reconnect. The problematic cache is only backend-lifetime. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers