Re: [HACKERS] Arrays broken on temp tables

> > I'm betting that something in the array code is somehow bypassing the
> > normal table lookup mechanism, and is managing to see the underlying
> > temp-table name that should be hidden from it.  Will look further...
> 
> Yup, here it is, in parse_target.c:
> 
>     /*
>      * If there are subscripts on the target column, prepare an
>      * array assignment expression.  This will generate an array value
>      * that the source value has been inserted into, which can then
>      * be placed in the new tuple constructed by INSERT or UPDATE.
>      * Note that transformArraySubscripts takes care of type coercion.
>      */
>     if (indirection)
>     {
>         Attr       *att = makeNode(Attr);
>         Node       *arrayBase;
>         ArrayRef   *aref;
> 
>         att->relname = pstrdup(RelationGetRelationName(rd)->data);
>                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Next question is what to do about it --- the original table name
> doesn't seem to be conveniently available in this routine.  A quick
> search for other uses of RelationGetRelationName shows other places
> that may have related bugs.  Possibly, temprel.c needs to provide
> a reverse-lookup routine that will give back the user name of a table
> that might be a temp table?

Well, I now wonder whether I did the right thing in adding temp tables
the way I did.  Is there a better way.  The current code maps to
original name to temp name on opens using the relcache.  That way, the
original name is passed all through the code.  When we print an error
message, we use the user-supplied name, not the temp name.

However, if the code reaches directly into the pg_class tuple and pulls
out the name, it will see the temp name.

Comments?

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