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