Re: global temporary tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: global temporary tables
Date
Msg-id 7796.1272125493@sss.pgh.pa.us
Whole thread Raw
In response to Re: global temporary tables  ("Greg Sabino Mullane" <greg@turnstep.com>)
Responses Re: global temporary tables  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
"Greg Sabino Mullane" <greg@turnstep.com> writes:
>> surprised to find my clone unaffected?  If it modifies both, how do we
>> avoid complete havoc if the original has since been modified (perhaps
>> incompatibly, perhaps not) by some other backend doing its own ALTER
>> TABLE?

> Since this is such a thorny problem, and this is a temporary table, why 
> not just disallow ALTER completely for the first pass?

Usually the way we approach these kinds of problems is that we want
to see some plausible outline for how they might be fixed before we
move forward with the base feature.  IOW, I wouldn't object to not
having ALTER in the first release, but if we have no idea how to do
ALTER at all I'd be too worried that we were painting ourselves into
a corner.

Or maybe you can make a case that there's no need to allow ALTER at
all, ever.  But surely DROP needs to be possible, and that seems to
already introduce some of the same issues.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Re: global temporary tables
Next
From: Simon Riggs
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Add missing optimizer hooks for function cost and number of rows.