>
> On Fri, 9 Jan 1998, Bruce Momjian wrote:
>
> > > Is CHAR padded on disk? Of course it should be padded for
> > > representation, but for storage, couldn't it be stored just like
> > > TEXT or VARCHAR? Before storing, it could be trimmed, and when
> > > read from storage, it could be padded with spaces on the right.
> >
> > Well, traditionally, CHAR() is fixed length, and VARCHAR() is variable.
> > This is how Ingres and Informix handle it.
>
> But how do we store this to the file system? If I setup a table
> with a char(20), and one of the records has a value of "a", does it then
> write 1 byte to the file system, or does it write 1 byte ("a") + 19 bytes
> ("")?
20+VARHDRSZ bytes for char(20), 1+VARHDRSZ for varchar(20)
>
> If the second, is there a reason why, as far as writing to the
> file system is concerned, char() can't be treated like varchar()? I'd
> imagine you could save one helluva lot of "disk space" by doing that, no?
But then you have variable length records where char(x) forces a fixed
length. Currently, the code treats all varlena structures as variable,
so we readly don't take advantage of this, but we may some day.
>
> Then again, thinkiing of it that way, I may as well just use
> varchar() instead, right?
Yep.
>
> See, this is what *really* gets me lost...I use text for
> everything, since I really haven't got a clue as to *why* I'd want to use
> either char() or varchar() instead...
>
> Now, from what I *think* I recall you stating, char() and
> varchar() are more for backwards compatibility? Compatibility with other
> SQL engines? If so...as long as we have a type char(), does our backend
> representation have to be any different between char() and text?
We need the fixed length trim cabability of char(), and I think we need
the padding of char() too.
--
Bruce Momjian
maillist@candle.pha.pa.us