Re: [HACKERS] temp table oddness?

> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Who knows. Once it gets messed up, anything can happen. The problem
> > with indexes created in the same transaction as the temp table still is
> > a problem, though you say your new cache code fixes that.
>
> No, I didn't say that. The weird "notice" isn't coming out any more,
> but I'm still seeing all these other bugs. It looks to me like there
> are problems with ensuring that an index on a temp table is (a) temp
> itself, and (b) built against the temp table and not a permanent table
> of the same name.

I thought this worked. In the regression tests, temp.sql has:

CREATE TABLE temptest(col int);

CREATE INDEX i_temptest ON temptest(col);

CREATE TEMP TABLE temptest(col int);

CREATE INDEX i_temptest ON temptest(col);

DROP INDEX i_temptest;

DROP TABLE temptest;

DROP INDEX i_temptest;

DROP TABLE temptest;

and works fine.

>
> I don't really understand how temp tables are implemented and whether
> relcache.c needs to be aware of them --- is there documentation
> somewhere?

That's a joke, right? :-)

temprel.c has:

/*
* This implements temp tables by modifying the relname cache lookups
* of pg_class.
* When a temp table is created, a linked list of temp table tuples is
* stored here. When a relname cache lookup is done, references to user-named
* temp tables are converted to the internal temp table names.
*
*/

get_temp_rel_by_name() is the workhorse. You can see the call to it in
ClassNameIndexScan(), which make the cache think the temp rel is a real
relation, and not just a temp one. Other access to the relation via oid
remain the same.

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