On Tue, Mar 1, 2016 at 9:30 PM, Robert Haas <[email protected]> wrote:
> On Tue, Mar 1, 2016 at 10:52 AM, Tom Lane <[email protected]> wrote: > > Aleksander Alekseev <[email protected]> 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.. -- Regards, Atri *l'apprenant*
