On Tue, Mar 1, 2016 at 10:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Aleksander Alekseev <a.alekseev@postgrespro.ru> writes: >> There are applications that create and delete a lot of temporary >> tables. Currently PostgreSQL doesn't handle such a use case well.
Yeah, I have a really hard time believing this can ever work. There are MANY catalog tables potentially involved here - pg_class, pg_attribute, pg_attrdef, pg_description, pg_trigger, ... and loads more - and they all can have OID references to each other. If you create a bunch of fake relcache and syscache entries, you're going to need to give them OIDs, but where will those OIDs come from? What guarantees that they aren't in use, or won't be used later while your temporary object still exists? I think making this work would make parallel query look like a minor feature.
Fair point, that means inventing a whole new OID generation structure..