Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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