From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | lifeair(at)gmail(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #6707: ERROR: could not open relation with OID |
Date: | 2012-06-27 03:51:14 |
Message-ID: | 20285.1340769074@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
lifeair(at)gmail(dot)com writes:
> CREATE OR REPLACE FUNCTION test() RETURNS integer AS
> $BODY$
> DECLARE
> _r RECORD;
> BEGIN
> CREATE TEMP TABLE test(id int);
> _r := ROW(NULL)::test;
> _r:=NULL;
> DROP TABLE test CASCADE;
> RETURN 1;
> END;
> $BODY$
> LANGUAGE plpgsql VOLATILE
> COST 100;
Hmm. The problem with this is that the DROP TABLE invalidates test's
rowtype, so on a second call the already-compiled "ROW(NULL)::test"
expression refers to a type that no longer exists.
We could fix that by adding datatypes to the set of objects that are
tracked to determine when a cached plan must be invalidated, but I'm
more than a bit hesitant to expend the extra cycles for this, given
the lack of previous complaints and the large number of datatypes
that are mentioned in most plans.
Perhaps it would be good enough to only track types that must be
rowtypes (ie, are mentioned in RowExpr or ConvertRowtypeExpr)?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Sachin Srivastava | 2012-06-27 05:40:15 | Re: BUG #6705: 32 bit |
Previous Message | digoal | 2012-06-27 00:02:53 | BUG #6708: pgsql_fdw's foreign table cann't used in plpgsql function |