Re: [HACKERS] temp table oddness?
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] temp table oddness? |
Дата | |
Msg-id | 199909041613.MAA22041@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] temp table oddness? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: