On Thu, Apr 26, 2012 at 10:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Apr 26, 2012 at 3:56 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> Previous discussions had Tom proposing ways of extending catalogs to
>>> allow exactly this. So designs that address that point are already on
>>> record.
>
>> Link?
>
> There was a thread a couple years ago ...
> http://archives.postgresql.org/pgsql-hackers/2010-10/msg01203.php
> particularly here:
> http://archives.postgresql.org/pgsql-hackers/2010-10/msg01448.php
>
> But I have a feeling that that idea is much older.
Yeah, so, basically this is what I already proposed upthread: put the
catalog entries for your temporary tables in system catalogs that are
themselves temporary tables. One difference is that you suggested
this could be done without GTTs by using LTTs that insert
bootstrapping entries describing themselves when they are initialized
- so you never need to modify the "real" pg_class, etc. I hadn't
thought of that, and it might be feasible. I have my doubts about
whether it's the path of least resistance because, as you point out
(and as Noah pointed out, and as I pointed out) any kind of change
that involves having moving some system catalog entries into a
separate set of temporary catalogs is likely to be extremely difficult
for many reasons. Noah's design is somewhat less powerful, but it
avoids getting sucked down that rathole.
In addition to the already-mentioned issue of temp->perm dependencies,
any such design would break the assumption that every table is
identified by a unique OID, which seems likely to break a whole lot of
things.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
