Peter Eisentraut <peter_e@gmx.net> writes:
> The clean solution would seem to be item
> * Allow char() not to use variable-sized header to reduce disk size
> where you would use the atttypmod as the length instead of the header. But
> a general solution like this would probably require too many structural
> changes.
Right now, *all* variable-length types have a varlena header, and
I think there isn't much of any way around that for internal
representation --- if Datums aren't self-sufficient then we've got
a real notational nightmare in the expression evaluator and function
call mechanism. Maybe we could make the inside-a-tuple representation
different from what gets passed around in expression evaluation, but
that sure looks like a can of worms to me. So I don't foresee this
TODO item getting done any time soon --- the cost/benefit ratio looks
way too high compared to all our other projects.
The reason the "allow access to char1" item is there is that I have an
application that has several different status indicators in each row
of a large table. I represented them as "char" values, which was both
useful for debugging ('P' = pending, etc) and compact, or so I thought.
When I realized that my status fields were not taking one byte apiece
as I expected, but eight bytes apiece (length word + alignment), I
wasn't happy.
We are using char1 as an enumerated type in several system fields
(relkind, for example) so I see no good reason why that type shouldn't
be available to user applications. It is actually possible to *make*
a char1 field in a user table:create table t1 (f1 "char");
but pg_dump won't reliably dump and restore this declaration because
it depends on a quoting hack not to be rewritten as bpchar(1) by the
parser.
regards, tom lane