> 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