Re: Temp tables, reports in Postgresql (and other RDBMS)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ow <oneway_111(at)yahoo(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Temp tables, reports in Postgresql (and other RDBMS)
Date: 2006-10-15 16:54:08
Message-ID: 23115.1160931248@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

ow <oneway_111(at)yahoo(dot)com> writes:
> We are considering moving some reports from *** to Postgres. Our reports are
> written as stored procs in Transact-SQL and usually have the following
> structure:
> ...
> How would one rewrite the above logic in Postgresql?

If that's all you have to do, then SQL-language functions ought to be
enough.

If you need some procedural logic (if-then-else stuff) then you'd need
to go over to plpgsql, which would be a bit of a pain because its habit
of caching query plans doesn't play nice with temp tables. Possibly you
could work some trick with ON COMMIT DELETE ROWS temp tables that are
created once at the start of a session and are auto-emptied after each
function by the ON COMMIT rule. Since the tables themselves don't
get dropped, there's no problem with plan invalidation.

There's also the possibility of using one of the other PLs such as
plperl, if you're familiar with any of the common scripting languages
they're based on. The other PLs don't do implicit plan caching so
they won't have problems with temp tables; but it does mean knowing
still another language and putting up with some notational inconvenience.

regards, tom lane

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message ow 2006-10-15 18:10:58 Re: Temp tables, reports in Postgresql (and other RDBMS)
Previous Message ow 2006-10-15 16:08:47 Temp tables, reports in Postgresql (and other RDBMS)