Greg Stark <stark(at)enterprisedb(dot)com> wrote:
> The whole point of having the schema declared in advance and then
> having each procedure execution have access to a private (or
> non-private) data store following that predefined schema is to avoid
> having to execute any catalog changes with all the locking and
> catalog i/o that DDL requires.
Global temporary tables are not shared between connections. Look back
to Pavel's original post; he's looking for a convenience -- a way to
have a temporary table materialized for a connection on reference,
"INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES". It is
not meant to be better in performance than creating a temporary table
explicitly on the fly and adding all these things, it's meant to
provide a consistent definition which can be materialized and used on
demand. Nothing more; nothing less. I understand not everyone has a
need for such a thing, but isn't that true of most features in
PostgreSQL?
If you're saying we can implement the standard's global temporary
tables in a way that performs better than current temporary tables,
that's cool. That would be a nice "bonus" in addition to the
application programmer convenience and having another tick-mark on the
standards compliance charts. Do you think that's feasible? If not,
the feature would be useful to some with the same performance that
temporary tables currently provide.
-Kevin