X-Original-To: pgsql-docs-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 0211F8B9F8D for ; Fri, 4 Feb 2005 17:03:51 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 29003-10 for ; Fri, 4 Feb 2005 17:03:48 +0000 (GMT) Received: from candle.pha.pa.us (candle.pha.pa.us [207.106.42.251]) by svr1.postgresql.org (Postfix) with ESMTP id 0A9FB8B9C34 for ; Fri, 4 Feb 2005 17:03:47 +0000 (GMT) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.11.6) id j14H3kE12325; Fri, 4 Feb 2005 12:03:46 -0500 (EST) From: Bruce Momjian Message-Id: <200502041703.j14H3kE12325@candle.pha.pa.us> Subject: Re: faq 4.20: pl/pgsql temporary tables create/drop In-Reply-To: <6EE64EF3AB31D5448D0007DD34EEB3412A760F@Herge.rcsinc.local> To: Merlin Moncure Date: Fri, 4 Feb 2005 12:03:46 -0500 (EST) Cc: pgsql-docs@postgresql.org X-Mailer: ELM [version 2.4ME+ PL121 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200502/15 X-Sequence-Number: 2848 Merlin Moncure wrote: > The PostgreSQL FAQ currently suggests using dynamic SQL as a workaround > for the table OID caching problem of temp tables in pg/pgsql functions. > While this is ok, it fails to suggest that besides the initial > create/drop statements, every statement that touches the table must also > be dynamic. > > With 8.0 comes pl/pgsql exception handlers...in the beginning of > function execution one might do the following: > begin > begin > delete from temp_table; -- temp table > exception > when others then > perform create temp temp_table [...] > end; > As long as the table structure does not change between function > executions, this can be a more elegant approach to dealing with this > problem. Pre 8.0, I would have suggested to initialize all temporary > tables in a special function, but this still requires special handling > code when the connection gets broken, etc. I think it would be helpful > to erstwhile pl/pgsql developers to list this alternative method here. Uh, the FAQ reads:

4.20) Why can't I reliably create/drop temporary tables in PL/PgSQL functions?

PL/PgSQL caches function scripts, and an unfortunate side effect is that if a PL/PgSQL function accesses a temporary table, and that table is later dropped and recreated, and the function called again, the function will fail because the cached function contents still point to the old temporary table. The solution is to use EXECUTE for temporary table access in PL/PgSQL. This will cause the query to be reparsed every time.

What should be changed? I see it saying "function accesses a temporary table". The word "access" suggests all access, not just create/drop. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073