Pavel Stehule <pavel.steh...@gmail.com> writes: > But there are some patterns used with work with temp tables,that should not > working, and we would to decide if we prepare workaround or not.
> -- problematic pattern (old code) > IF NOT EXISTS(SELECT * FROM pg_class WHERE ....) THEN > CREATE TEMP TABLE xxx() > ELSE > TRUNCATE TABLE xxx; > END IF; > -- modern patter (new code) > BEGIN > TRUNCATE TABLE xxx; > EXCEPTION WHEN ..... THEN > CREATE TEMP TABLE(...) > END; If the former stops working, that's a sufficient reason to reject the patch: it hasn't been thought through carefully enough. The key reason why I don't think that's negotiable is that if there aren't (apparently) catalog entries corresponding to the temp tables, that will almost certainly break many things in the backend and third-party extensions, not only user code patterns like this one. We'd constantly be fielding bug reports that "feature X doesn't work with temp tables anymore". In short, I think that the way to make something like this work is to figure out how to have "virtual" catalog rows describing a temp table. Or maybe to partition the catalogs so that vacuuming away temp-table rows is easier/cheaper than today. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers