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

Forwarded message:
> > The problem was that some things were copied using VARSIZE rather than
> > subtracting out VARHDRSZ first (actually, I think it might have use
> > sizeof(int) and other dangers too). I patched that near the end of the year
> > and my 980101.d tree and 980106.d tree do not exhibit the symptom:
> >
> > postgres=> create table t (v varchar(80),i int);
> > CREATE
> > postgres=> insert into t values ('hi', 1);
> > INSERT 643562 1
> > postgres=> select * from t;
> > v |i
> > --+-
> > hi|1
> > (1 row)
>
> I have found that ExecEvalVar() uses a descriptor that has the attr
> length set to the maximum, instead of -1.  The ExecTypeFromTL() comment
> says:
>
> /* ----------------------------------------------------------------
>  *      ExecTypeFromTL
>  *
>  *      Currently there are about 4 different places where we create
>  *      TupleDescriptors.  They should all be merged, or perhaps
>  *      be rewritten to call BuildDesc().
>  *
>
> Clearly stating that the tuple descriptors in the system are created in
> several places.  Some places have the length set wrong.  I am going to
> have to take a look at all those places, and make sure they have
> consistent behaviour.

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.

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