Fair point, that means inventing a whole new OID generation structure..
Generation is just the tip of the iceberg. You still need the equivalent to foreign keys (ie: pg_depend). While you would never have a permanent object depend on a temp object, the reverse certainly needs to be supported.
If I were attempting to solve this at a SQL level, I'd be thinking about using table inheritance such that the permanent objects are stored in a permanent parent. New backends would create UNLOGGED children off of that parent. There would be a pid column that was always NULL in the parent, but populated in children. That means children could use their own local form of an OID. When a backend terminates you'd just truncate all it's tables.
Actually translating that into relcache and everything else would be a serious amount of work.
you have to store some metadata outside catalogue - in this moment is not important the syntax or architecture (global temp tables or fast temp children tables). You have not to use catalogue (when you use catalogue, then you have bloating). But these special information are related mostly to planner and should not be MVCC (number of pages, rows, statistics), and because we are talking about temp tables, you can use session memory.
Regards
Pavel
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
