Re: [9.0] On temporary tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: [9.0] On temporary tables
Date: 2010-09-30 13:47:04
Message-ID: 5435.1285854424@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it> writes:
> create or replace function session_init()
> returns void
> language plpgsql
> as $body$
> declare
> t text;
> begin
> select valu into t from session where name='SESSION_ID';
> if not found then
> create temporary table session ( like public.session including all );
> insert into session values ( 'SESSION_ID',current_user );
> end if;
> end;
> $body$;

> The idea is to create a temporary table to store session variables
> only of there's no temporary table with that name.

That isn't going to work tremendously well. plpgsql will cache a plan
for that SELECT on first use, and creation of the temp table is not an
event that will cause replanning of a select that doesn't already use
the temp table.

If you're dead set on this design (which frankly doesn't seem like a
terribly great idea to me), try doing the initial probe with an EXECUTE
so it'll be replanned each time.

Or you might try examining the system catalogs directly rather than
relying on an attempted table access, eg

if not exists (select 1 from pg_catalog where relname =
'session' and pg_table_is_visible(oid))
then ... create it ...

That approach would work best if you *didn't* have any permanent
table that the temp tables were masking, which on the whole seems
like a smarter plan to me.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Vincenzo Romano 2010-09-30 13:52:19 Re: [9.0] On temporary tables
Previous Message Igor Neyman 2010-09-30 13:36:17 Re: Prepared statements and unknown types