Sean Chittenden <[EMAIL PROTECTED]> writes:
> Hrm... this limitation makes temporary tables that drop on commit +
> pl/pgsql unusable beyond the 1st transaction. Is there a mechanism to
> test to see if a relation in a plan is a temporary table? It seems as
> though in pl_exec.c that around 1926 it'd be possible to add a test to
> see if the plan uses temporary tables and add a new member to struct
> expr telling exec_stmt_execsql to free the plan around line 2016 when
> its cleaning up after itself.
That's entirely the wrong way to go about it. Temp tables are only one
manifestation of a general problem with stale plans. For instance, if
someone drops an index that your query uses, you've got a problem.
What we need is a general mechanism that keeps track of all the DB
objects that a cached plan depends on (tables, views, functions, yadda
yadda) and invalidates the plan when any of those objects are dropped or
altered. At the low level, such a mechanism already exists (the
syscache inval stuff) --- the problem is to connect it up to plan
caching.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
