Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Can we actually get rid of pg_class entries for temp tables. Maybe
>> creating a "temp pg_class" which would be local to each session? Heck,
>> it doesn't even have to be an actual table -- it just needs to be
>> somewhere from where we can load entries into the relcache.
>
> A few things to think about:
>
> 1. You'll break a whole lotta client-side code if temp tables disappear
> from pg_class.
> 2. How do you keep the OIDs for temp tables (and their associated
> rowtypes) from conflicting with OIDs for real tables?
> 3. What about dependencies on user-defined types, functions, etc?
Is there not some gain from just a "standard" partitioning of pg_class
into: (system-objects, user-objects, temp-objects)? I'd expect them to
form a hierarchy of change+vacuum rates (if you see what I mean).
--
Richard Huxton
Archonet Ltd
