Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> ... the whole business of temprels having different physical and
>> logical relnames will go away anyhow. Temp rels will become plain rels
>> that live in a temp schema.
> I don't think this is the right solution. You should be able to create
> temporary tables in any schema you choose (and have permission to). After
> all, temporary tables are supposed to act like real tables expect for the
> "temporary" aspect.
If we did that, temp table names would conflict with real table names.
The lack of conflicts is one of the (few ;-)) features of our current
temp table implementation that I really like. Furthermore, I read in
SQL92 sec 4.9
... because global temporary ta- ble contents are distinct within SQL-sessions, and created local
temporarytables are distinct within <module>s within SQL-sessions, the effective <schema name> of the schema in
whichthe global tem- porary table or the created local temporary table is instantiated is an
implementation-dependent<schema name> that may be thought of as having been effectively derived from the <schema
name>of the schema in which the global temporary table or created local temporary table is defined and
theimplementation-dependent SQL- session identifier associated with the SQL-session. In addition, the
effective<schema name> of the schema in which the created local temporary table is instantiated may be thought
ofas being further qualified by a unique implementation-dependent name associ- ated with the <module> in
whichthe created local temporary table is referenced.
This appears to me to require that it be done in the way I suggest:
temp tables live in their own per-backend schema, or schemas.
regards, tom lane
