Robert Haas <robertmh...@gmail.com> writes: > At least AIUI, the use case for this feature is that you want to avoid > creating "the same" temporary table over and over again.
The context that I've seen it come up in is that people don't want to clutter their functions with create-it-if-it-doesn't-exist logic, which you have to have given the current behavior of temp tables. Any performance gain from reduced catalog churn would be gravy. Aside from the DROP problem, I think this implementation proposal has one other big shortcoming: what are you going to do about table statistics? In many cases, you really *have* to do an ANALYZE once you've populated a temp table, if you want to get decent plans for it. Where will you put those stats? 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