varchar() change - Mailing list pgsql-hackers

From Bruce Momjian
Subject varchar() change
Date
Msg-id 199801080431.XAA05315@candle.pha.pa.us
Whole thread Raw
List pgsql-hackers
Let me go over the issues with the varchar() change.

char() will continue to store full bytes, while varchar() function like
text, but with a limited length.

Now, pg_attribute.attlen is access everywhere, trying to find out how
long the data field is.  With text, the length is -1, but with varchar
currently, it is the max length, and hence, it has to store all those
bytes.

Now, my idea is to add a new pg_attribute column called 'attmaxlen'
which will hold the maximum length of the field.  char() and varchar()
will use this field, and the code will have be changed.  Cases where
attlen is referenced to determine data size will continue to use -1, but
references to all functions that create a data entry will use the
attmaxlen.  I see 124 references to attlen in the code.  Not too bad.
Most are obvious.

We had some of this work in the past, fixing places where the size was
not properly passed into the table creation code, because varchar() and
char() do not have lengths defined in pg_type like everyone else, but it
is only in pg_attribute.

This is a related change to allow data reference and tuple max length
reference to be separate.  I can see other new types using this field
to.

Come to think of it, I wonder if I could have the disk copy of
pg_attribute use the pg_type length, and use the pg_attribute length
only when creating/updating entries?  I wonder if that is what it does
already.  Looks like that may be true.

Comments?

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

pgsql-hackers by date:

Previous
From: "Vadim B. Mikheev"
Date:
Subject: Re: [HACKERS] rollback varchar change
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] rollback varchar change