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
