Re: [HACKERS] Arrays broken on temp tables
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Arrays broken on temp tables |
Дата | |
Msg-id | 13261.942287167@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Arrays broken on temp tables (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Arrays broken on temp tables
|
Список | 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 по дате отправления: