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