Re: [HACKERS] Re: varchar() troubles (fwd)

> 
> Bruce Momjian wrote:
> > 
> > >
> > > I have found that ExecEvalVar() uses a descriptor that has the attr
> > > length set to the maximum, instead of -1.  The ExecTypeFromTL() comment
> ...
> > 
> > Vadim, can you look at this for me.  If you set a break at ExecEvalVar
> > before executing the SELECT, you will see its
> > tupledescriptor->attrs[0].attlen is the max length, and not -1 as it
> > should be.
> > 
> > I can't figure out where that is getting set.  Can you also check the
> > other tupledescriptor initializations to see they have the -1 for
> > varchar too.  I am stumped.
> 
> Why attlen should be -1 ?
> attlen in pg_attribute for v in table t is 84, why run-time attlen
> should be -1 ? How else maxlen constraint could be checked ?
> IMHO, you have to change heap_getattr() to check is atttype == VARCHAROID
> and use vl_len if yes. Also, other places where attlen is used must be 
> changed too - e.g. ExecEvalVar():
> 
>     {
>         len = tuple_type->attrs[attnum - 1]->attlen;
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         byval = tuple_type->attrs[attnum - 1]->attbyval ? true : false;
>     }
> 
>     execConstByVal = byval;
>     execConstLen = len;
>     ^^^^^^^^^^^^^^^^^^ - used in nodeHash.c
> 

The major problem is that TupleDesc comes from several places, and
attlen means several things.

There are some cases where TupleDesc (int numatt, Attrs[]) is created
on-the-fly (tupdesc.c), and the attlen is the length of the type.  In
other cases, we get attlen from opening the relation, heap_open(), and
in these cases it is the length as defined for the particular attribute.

Certainly a bad situation.  I am not sure about a fix.


-- 
Bruce Momjian
maillist@candle.pha.pa.us