Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> But for a temp table, what really gets emitted from the
>> parser is effectively like
>>
>> UPDATE logtable SET arrayfield = arrayinsert(phytable.field,
>> sub, val)
>> FROM logtable phytable;
>>
> OK, I see it now. They are assigning the relname at this point using
> the in-tuple relname, which is the physical name, not the logical name.
Right, the array-element-update code needs to generate a reference
using the logical name.
> If I look at all calls to RelationGetRelationName(), I can see several
> problem cases where the code it assigning the rel/refname based on the
> in-tuple name.
I suspected as much, but I haven't grovelled through the calls in
detail. Some of them probably really do want the physical name,
while others need the logical name.
> Ideas? Should i add reverse-lookup code in temprel.c, and make the
> lookups happen for those cases?
We could do it that way, but as the code stands, relcache.c is
responsible for the forward lookup (you just pass a rel name to
heap_openr without worrying if it is a temp rel name or not).
So I think relcache.c ought to provide a function or macro to
go the other way: produce a logical relname from a Relation pointer.
Whether that's implemented by copying the originally given relname
into the relcache entry, or by asking temprel.c each time, is purely
a local optimization inside relcache.c --- it's a straight speed-for-
space tradeoff. Before choosing, we should look at the uses of
RelationGetRelationName() to see if any of them that need to be
fetching the logical name are in performance-critical paths.
regards, tom lane
