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: <k2y603c8f071004241016w48b9d39an2dbf6d9df2bad495@mail.gmail.com> 
References: <fca910820578d251cc1d5647793c9a67@biglumber.com>
	<7796.1272125493@sss.pgh.pa.us>
	<k2y603c8f071004241016w48b9d39an2dbf6d9df2bad495@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Sat, 24 Apr 2010 13:16:20 -0400"
Date: Sat, 24 Apr 2010 13:38:46 -0400
Message-ID: <9452.1272130726@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

[ forgot to respond to this part ]

Robert Haas <robertmhaas@gmail.com> writes:
> ...  I don't see the problem with DROP.
> Under the proposed design, it's approximately equivalent to dropping a
> table that someone else has truncated.  You just wait for the
> necessary lock and then do it.

And do *what*?  You can remove the catalog entries, but how are you
going to make the physical storage of other backends' versions go away?
(To say nothing of making them flush their local buffers for it.)
If you do remove the catalog entries, won't you be cutting the knees
out from under whatever end-of-session cleanup processing might exist
in those other backends?

The idea of the global table as a template that individual sessions
clone working tables from would avoid most of these problems.  You
rejected it on the grounds that ALTER would be too hard; but if you're
blowing off ALTER anyway, that argument seems pretty unimpressive.

			regards, tom lane