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(at)candle(dot)pha(dot)pa(dot)us