Re: [HACKERS] varchar/char size

Bruce Momjian wrote:
>
> Does someone want to remind me why we allocate the full size for char()
> and varchar(), when we really can just allocate the size of the given
> string?
>
> I relize char() has to be padded, but why varchar()?
>
> In my experience, char() is full size as defined by create, and
> varchar() is the the size of the actual data in the field, like text,
> but with a pre-defined limit.

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.

Btw, why is VARCHAR not simply an alias for TEXT, with maxlen added?
Shouldn't these types be the same internally, but with maxlen checked
for VARCHAR in the parser and maxlen set to "infinite"(-1?) for TEXT?
Or perhaps CHAR could be put into the same type also?

If we have a type called VARTEXT(int maxLen, bool doPaddingProcessing):

VARCHAR(10) becomes VARTEXT(10, false)    // 10 chars, no padding
TEXT becomes VARTEXT(0, false)        // infinite length, no padding
CHAR(10) becomes VARTEXT(10, true)    // 10 chars, padded

Would not this be easier to handle than three different types? This
type stuff would be handled in the parser. There would be only one
storage function, which could do any kind of coding to make the VARTEXT
take as little space as possible on disk.
Perhaps it would (in some cases) be good to have the possibility to
specify compression of the text. That could be another bool attribute
to VARTEXT, used by "COMPRESSED VARCHAR()" or "COMPRESSED TEXT" so that
people can squeeze the maximum out of their disk space.

A related question: Is it possible to store tuples over more than one
block? Would it be possible to split a big TEXT into multiple blocks?

/* m */