I don't understand why an implementation taking approach 2.a would be useless. As I said, its performance will be no worse than current temp tables and it will provide a lot of convenience to users who need to create temp tables in every session.
Surely it should be step forward. But you will to have to solve lot of problems with "duplicated" tables in system catalogue, and still it doesn't solve the main problem with temporary tables - the bloating catalogue - and related performance degradation.
That being the "main" problem is strictly a matter of opinion based on your experience. Many people don't have a performance problem today, but do have to deal with all the pain of handling this manually (as well as all the limitations that go with that).
If it's easy to fix the bloat problem at the same time as adding GLOBAL TEMP then great! But there's no reason to reject this just because it doesn't fix that issue.
Agreed
There are some good arguments for why we need this feature.
Pavel's original description of how to do this seem valid, and from the link Tom agreed in 2009.
For me the design summary is this
* CREATE GLOBAL TEMP TABLE creates catalog entries like a normal table but with different relkind
* When we see a request to INSERT, DEL, UPD, SEL from the temp table, if it does not exist we create it as a TEMP table of the same name, using the Global's pg_class entry as a template
That meets the SQL Standard and doesn't contain any visibility problems or need for new internals.
The purpose of this feature is to automatically create a temp table with the same definition whenever needed. The discussion of "bloat" is just wrong. We create exactly the same amount of bloat as if we had typed CREATE TEMP TABLE. Optimising temp table entries in the catalog is another, separate patch, if we care.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services