Re: global temporary tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: global temporary tables
Date
Msg-id 9452.1272130726@sss.pgh.pa.us
Whole thread Raw
In response to Re: global temporary tables  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: global temporary tables  (Robert Haas <robertmhaas@gmail.com>)
Re: global temporary tables  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
[ 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: global temporary tables
Next
From: Robert Haas
Date:
Subject: Re: global temporary tables