To: Robert Haas <robertmhaas@gmail.com>
cc: Greg Sabino Mullane <greg@turnstep.com>, pgsql-hackers@postgresql.org
Subject: Re: global temporary tables 
In-reply-to: <j2n603c8f071004241151xb8ac9c44k566e8c52c40574a3@mail.gmail.com> 
References: <fca910820578d251cc1d5647793c9a67@biglumber.com>
	<7796.1272125493@sss.pgh.pa.us>
	<k2y603c8f071004241016w48b9d39an2dbf6d9df2bad495@mail.gmail.com>
	<9452.1272130726@sss.pgh.pa.us>
	<j2n603c8f071004241151xb8ac9c44k566e8c52c40574a3@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Sat, 24 Apr 2010 14:51:34 -0400"
Date: Sat, 24 Apr 2010 15:51:01 -0400
Message-ID: <11887.1272138661@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Robert Haas <robertmhaas@gmail.com> writes:
> ...  Why would the
> end-of-session processing need the catalog entries?  It seems like
> whatever backend-local data structure we're using to record the
> relfilenode mappings would be sufficent to nuke the backend storage,
> and what else needs doing?

Well, if you're intending to have a separate data structure and code
path for cleaning up this type of temp table, then maybe you don't need
to touch any catalog entries.  I'm concerned though about how far the
effects will propagate --- things like TRUNCATE, VACUUM FULL, REINDEX
will probably have issues with this.  Right now they think in terms
of writing a new pg_class entry in order to reassociate tables with
new relfilenodes.

Have you thought much about the previously proposed design, ie keeping
catalog entries for temp tables in backend-local temporary catalogs?
That would certainly be a lot of work, but I think in the end it might
fit in better.  This design feels like it's being driven by "hey,
we can abuse the relmapper to sort of do what we want", and not by
what we really want.

			regards, tom lane