> 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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers