| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> | 
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: [PATCHES] Removal of temp tables | 
| Date: | 2001-06-14 15:23:29 | 
| Message-ID: | 18010.992532209@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches | 
Peter Eisentraut <peter_e(at)gmx(dot)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
         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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2001-06-14 16:31:54 | Doing authentication in backend | 
| Previous Message | Peter Eisentraut | 2001-06-14 15:15:07 | Re: [PATCHES] Removal of temp tables | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2001-06-14 16:36:48 | Re: Removal of temp tables | 
| Previous Message | Peter Eisentraut | 2001-06-14 15:15:07 | Re: [PATCHES] Removal of temp tables |