--- Tom Lane <tgl@sss.pgh.pa.us> wrote:
> If you need some procedural logic (if-then-else stuff)
Yes
> 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.
Going to plpgsql is fine. What I'm trying to understand is how one goes about
writing reports in Postgres as per our scenario, be that with temp tables,
cursors, RECORDs, ROWTYPEs, etc.
In our RDBMS we use temp tables because it's the easiest way to take some table
as a base for your report and then extend it, as needed, with additional
columns, as I showed in step (1). Also, once the stored proc has run, the temp
table is automatically dropped, no need to worry about it. How does one go
about in Postgres? Do people use cursors or whatever instead of temp tables?
> 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.
Not sure I understand. Our plan was actually to drop the temp table ON COMMIT,
because it's stor proc that creates the temp table. If the session already has
the temp table then creating it in stored proc again will fail, no?
Thanks
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com