Tom Lane <t...@sss.pgh.pa.us> wrote: > I was thinking in terms of throwing a warning in 8.4 and > implementing new behavior in 8.5. If we're on that time frame with it, I guess it's not too early to suggest what we would implement in 8.5. I would suggest that it is clear that what Pavel is requesting is fully compliant with the spec's definition of global temporary tables. Since the essence of "global" in this context is that they are not constrained by modules, the absence module support doesn't seem to create any possible compatibility issue when and if modules are added. I would suggest (with somewhat less confidence) that both created and declared local temporary tables might make sense in the context of whatever procedural languages are supported. In PL/pgSQL, for example, the declaration for a declared local tempoary table would be allowed inside the PL's BEGIN block, in the area where local variables are allowed. Such a table would be visible only within the context of the block (meaning we would probably need to munge the name somehow to support recursion or other functions with a duplicate table name). The temporary table would be materialized at the point where it is declared, and dropped at the END of the block. I not clear on whether a created local temporary table should retain its contents from one invocation of a function to the next. I'm inclined to think it shouldn't -- that the scope for a materialized instance is the same as a declared local tempoarary table; the CREATE just ensures a consistent definition wherever used. Or perhaps it's just a bad idea to attempt to use the LOCAL syntax outside of a proper module at all. The GLOBAL option seems clear; LOCAL seems a bit muddy to me. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
