Re: [HACKERS] temp table oddness? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] temp table oddness?
Date
Msg-id 199909041613.MAA22041@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] temp table oddness?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Here's another case that doesn't work too well:
> 
> regression=> create table u1(i int);
> CREATE
> regression=> insert into u1 values(1);
> INSERT 150665 1
> regression=> insert into u1 values(1);
> INSERT 150666 1
> regression=> create temp table u1(i int);
> CREATE
> regression=> create unique index i_u1 on u1(i);
> CREATE
> regression=> select * from u1;        -- yup, temp table is empty
> i
> -
> (0 rows)
> 
> regression=> drop table u1;        -- drop temp table
> DROP
> regression=> select * from u1;        -- ok, we're back to permanent u1
> i
> -
> 1
> 1
> (2 rows)

Gee, I was doing so well up to this point.

> 
> regression=> begin;
> BEGIN
> regression=> create temp table u1(i int);
> CREATE
> regression=> create unique index i_u1 on u1(i);
> ERROR:  Cannot create index: 'i_u1' already exists
> -- apparently, dropping a temp table doesn't drop its temp indexes?
> regression=> end;
> END
> regression=> select * from u1;
> ERROR:  cannot find attribute 1 of relation pg_temp.24335.3
> -- oops, what's causing this?  Shouldn't the xact have been rolled back
> -- due to error?
> regression=> \q
> -- backend coredumps on quit
> 
> 
> Looks like indexes on temp tables need some serious work :-(

It is the existance of the temp in transactions that is causing a
problem.


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] temp table oddness?
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] temp table oddness?