varchar() fix

OK, I now figured out why the initial code was not working.  It was not
constant null padding, but the fact that the old vcTruetype did not
include VARHDRSZ, and VARSIZE does, to strncmp() was comparing junk
bytes.

Now, with the proper VARSIZE() - VARHDRSZ, things work fine.  No varlena
structure changes, and no new columns.

The funny thing is that with varchar() and char(), because they are
fixed length for all data but are also varlena, they seem to work fine
in the code as -1 or as the default size plus VARHDRSZ, so code works no
matter how it is referenced.

With our new change, this will not work.  Data access MUST use the type
length of -1, and maximum length checks must be performed using the
pg_attribute length.

Fortunately, it looks like all the 'attlen' references I saw already had
the proper handling, in part to fix problems we had in creating tables,
like the old SELECT INTO TABLE bug for varchar, where all the varchar
lengths were -1.

It turns out the old code could use -1 or the max length, but had to use
the max length when creating tables, and we hacked that around to get it
working.

Now, it turns out the only way to get stuff into a able is through
INSERT with a constant, data from another table, or COPY, and I think we
check all of those for proper length already.  In fact, we can reduce
the restriction that the old just not be longer than the new.

I can't see any place where the system uses the pg_attribute length over
the pg_type length.

The Descriptor tuple is type length, execept when a table is being
created, but that makes sense.

Let's let it run for a while and see if any problems come up.  If
someone wants to hunt through the code looking for a possible problem,
go ahead.

I think it as important feature for people using varchar(), and
hopefully if there is a problem, testing will bring it out.  Usually a
problem of this nature will show itself fairly early.

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