Thread: plpgsql TEMP table issue not fixed in 8.1?
Folks, I'd swear somebody committed a fix for the issue with temp tables inside plpgsql functions, like, months ago. Yet I still get: ERROR: relation with OID 16607 does not exist CONTEXT: SQL statement "INSERT INTO tmp_runs ( run_id, batch, machine ) VALUES ( NEXTVAL('runs_run_id_seq'), $1 , $2 [ $3 ] )" PL/pgSQL function "generate_test_series" line 67 at SQL statement ERROR: relation with OID 16607 does not exist This is CVS as of a week ago. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus <josh@agliodbs.com> writes: > I'd swear somebody committed a fix for the issue with temp tables inside > plpgsql functions, like, months ago. Nope. regards, tom lane
>Folks, >=20 >I'd swear somebody committed a fix for the issue with temp tables inside=20 >plpgsql functions, like, months ago. Yet I still get: =20 >ERROR: relation with OID 16607 does not exist >CONTEXT: SQL statement "INSERT INTO tmp_runs ( run_id, batch, machine )=20 >VALUES ( NEXTVAL('runs_run_id_seq'), $1 , $2 [ $3 ] )" > PL/pgSQL function "generate_test_series" line 67 at SQL statement >ERROR: relation with OID 16607 does not exist =20 I'm having a similar problem: =20 ERROR: relation with OID 7121526 does not exist CONTEXT: SQL statement "SELECT * INTO temp tmp_resourcequeue from resourcequeue where timeblockid in (select timeblockid from tmp_timeblock)" PL/pgSQL function "archivetimeblocks" line 54 at SQL statement =20 Works the first time, but not the second... even tho the temp table has been explicitly dropped between executions. =20 Is there a fix or workaround for this yet? =20 =20 Jim Klo Sr. Web Systems Engineer Web Associates http://webassociates.com =20
On Thu, 2005-12-15 at 11:09 -0800, Jim Klo wrote: > Im having a similar problem: > > ERROR: relation with OID 7121526 does not exist > CONTEXT: SQL statement "SELECT * INTO temp tmp_resourcequeue from resourcequeue where timeblockid in (select timeblockidfrom tmp_timeblock)" > PL/pgSQL function "archivetimeblocks" line 54 at SQL statement > > Works the first time, but not the second even tho the temp table has been explicitly dropped between executions. > > Is there a fix or workaround for this yet? Only the workarounds that have always existed: drop and recreate the function, disconnect and then reconnect the client application, or reference the temp table using EXECUTE only. The underlying problem (invalidation of cached query plans) has not yet been fixed. -Neil