Peter Eisentraut <[EMAIL PROTECTED]> 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
temporary tables are distinct within <module>s within SQL-sessions,
the effective <schema name> of the schema in which the 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 the implementation-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 of as being
further qualified by a unique implementation-dependent name associ-
ated with the <module> in which the 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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
