> Tom Lane wrote:
> "Kevin Grittner" writes:
>> Because the current support for temporary tables is relatively
>> similar to the standard's description of LOCAL TEMPORARY TABLES,
>> but nothing at all like the standard's descri0ption of GLOBAL
>> TEMPORARY TABLES.
>
> Um ... did you read the spec before stating that?
Well, I did, but not recently. Clearly I should not have trusted my
memory.
A fresh review brought it all back to me. When I was reviewing the
standard (in 1998) to decide what to implement for the SQL parser in
the Wisconsin Courts framework I was designing, I decided to
effectively consider any "compound statement" block (delimited by
BEGIN/END) in a trigger or stored procedure to be equivalent to a
module in terms of features such as temporary tables -- because we
didn't have a concept of modules and wanted to borrow features from
the standard which were defined in terms of modules. So over the
years I muddled what was in the standard with implementation details
of our framework. I apologize for the confusion.
So there are three types of temporary tables defined in the standard,
and the PostgreSQL implementation doesn't look like any of them. The
bad thing is that PostgreSQL supports syntax for two of them without
matching the standard semantics. :-(
CREATE TEMPORARY TABLE (without LOCAL or GLOBAL) would be an
extension which could not be confused with standard syntax, so
arguably refusing to accept those would be the right thing to do from
a standards compliance perspective -- it would be a legitimate
PostgreSQL extension that way, but the breakage of working code which
would result from suddenly doing that could never be considered
acceptable.
What to do about all this?
Unless we expect to implement modules in the next release or two,
perhaps we should address the LOCAL noise-word in the docs, with a
note that its usage is non-standard and discouraged since it might
conflict with standard usage in future releases. Since we've had an
actual patch submitted for implementing GLOBAL temporary tables,
perhaps that merits a run-time warning in 9.2 (also supported by a
warning in the docs).
I think we've dug ourselves into a hole by supporting standard syntax
with non-standard semantics. As the saying goes, when you find
yourself in that position, the first thing to do is to stop digging.
-Kevin