--- Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
