From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] TODO list check |
Date: | 2000-01-29 15:58:37 |
Message-ID: | 14738.949161517@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-01-29 15:59:21 | Re: [HACKERS] END/ABORT |
Previous Message | Hiroshi Inoue | 2000-01-29 15:48:36 | RE: [HACKERS] [6.5.2] potentially major bug? |