Re: [HACKERS] Arrays broken on temp tables

Bruce Momjian <maillist@candle.pha.pa.us>

From: Bruce Momjian <maillist@candle.pha.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kristofer Munn <kmunn@munn.com>, pgsql-hackers@postgresql.org
Date: 1999-11-07T12:58:01Z
Lists: pgsql-hackers
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > Well, I now wonder whether I did the right thing in adding temp tables
> > the way I did.  Is there a better way.
> 
> I don't think there's anything wrong with the basic temp table design.
> We've just discovered an oversight: given a Relation entry, there's no
> way to get back the original table name, and sometimes you need to.
> 
> I'm inclined to think that RelationGetRelationName should be replaced
> by two access macros: one to give back the "physical" rel name (same
> as the current macro) and one to give back the "logical" name, which'd
> be different in the case of a temp table.  We'd need to extend relcache
> entries to include the logical name as an additional field.  Then we'd
> need to look at all the uses of RelationGetRelationName to see which
> ones should be which.  There might be some direct accesses to
> rel->rd_rel->relname as well :-( which need to be found and fixed.

OK, one more comment.

Because both physical and logical names map to the same oid, in _most_
cases it doesn't matter if RelationGetRelationName returns the physical
name.

Any idea why the physical name causes a problem in this area of the
code?

Also, I believe I replaced most cases of rd_rel->relname with
RelationGetRelationName during one of my cleanups long ago.  Seems I had
not done this case because I see lots of them.  Adding macro call now.

BTW, it is quite easy to add reverse lookup in cache if that will fix
things.


-- 
  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, Pennsylvania 19026