Re: [HACKERS] Arrays broken on temp tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Arrays broken on temp tables
Date
Msg-id 13261.942287167@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Arrays broken on temp tables  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] Arrays broken on temp tables  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> 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.

> 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?

The problem is that the rangetable code doesn't realize that the logical
and physical names refer to the same table, so when the
subscript-processing code generates a reference to
<physicaltablename>.<attribute> the parser generates a second RTE for
the physical table name, in addition to the already-existing RTE for the
logical table name.  This causes the planner to generate a join, because
it can see no difference between this situation andFROM tablename, tablename aliasname
which *should* cause a join.  But the join causes each tuple to be
processed multiple times, which is the wrong thing for this case.

There is more than one way we could attack this, but I think the
cleanest answer will be to make it possible to extract a logical
table name from a relcache entry.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Indent
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] New psql compile problem.