Re: [HACKERS] Re: varchar() troubles

>
> > Pretty sure only after but it's hard to tell for sure. My trees for 971204
> > and 971222 both core dump on inserts to varchar, but I can't remember what
> > else I was doing with the trees at the time.
>
> I now recall that the varchar code was broken during this time (for who knows
> how long?), as I discovered when trying to reproduce the tutorial results for
> the documentation.
>
> 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.

--
Bruce Momjian
maillist(at)candle(dot)pha(dot)pa(dot)us