Re: [HACKERS] temp table oddness?

> Bruce Momjian <maillist@candle.pha.pa.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
INDEXi_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
linkedlist of temp table tuples is* stored here.  When a relname cache lookup is done, references to user-named* temp
tablesare 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@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