To: Robert Haas <robertmhaas@gmail.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: global temporary tables 
In-reply-to: <z2r603c8f071004232018k9891b0f8p5fcb1708455f462d@mail.gmail.com> 
References: <u2o603c8f071004231952i36642ae6u9d6a7eae6eb6ff32@mail.gmail.com>
	<24194.1272078682@sss.pgh.pa.us>
	<z2r603c8f071004232018k9891b0f8p5fcb1708455f462d@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Fri, 23 Apr 2010 23:18:29 -0400"
Date: Fri, 23 Apr 2010 23:28:48 -0400
Message-ID: <24898.1272079728@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Apr 23, 2010 at 11:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I also kind of wonder what is supposed to happen if someone DROPs or
>> ALTERs the temp table definition ...

> ...not so much.  Here you REALLY want a DROP attempt to acquire an
> AccessExclusiveLock that will conflict with any outstanding
> AccessShareLocks.  Similarly, you're only going to be able to modify
> the schema for the relation if it's not otherwise in use.

I think you're presuming the answer to the question.  We could also view
the desired behavior as being that each session clones the temp table
definition at some instant (eg, first use).  The approach that you're
assuming seems fraught with large downsides: in particular, implementing
ALTER TABLE would be a mess.  The would-be alterer would need access to
the physical copies of all sessions, which throws out not only the
assumption that the relmapper entries can be private data, but all of
the access optimizations we currently have in the local buffer manager.
Not to mention the coding mess of having to repeat the ALTER operation
for each of N copies, some of which might disappear while we're trying
to do it (or if they don't, we're blocking backends from exiting).
I don't even know how you'd do the ALTER over again N times if you
only have one set of catalog entries describing the N copies.

			regards, tom lane