Thread: char type seems the same as char(1)
The Postgres documentation (chapter "Data Types" in the User's Manual)
states that type char is a single byte, whereas char(n) requires 4+n
bytes. Some experimentation, however, shows that "char" is actually
equivalent to char(1) --- it takes 5 bytes to store, even though psql's
"\d table" command lies and claims it takes only 1. Worse, the field
requires 4-byte alignment, which means if you have several of them
in a row, it's costing you 8 bytes apiece.
Is this a documentation error, or a code bug? If not a bug, is there
any other way to store a character as a single-byte field? I'm
currently using char fields all over the place as "poor man's enumerated
type" values, and I'm rather annoyed to find that what I thought was
taking 1 byte per field is actually taking 8...
regards, tom lane
> The Postgres documentation (chapter "Data Types" in the User's Manual) > states that type char is a single byte, whereas char(n) requires 4+n > bytes. Some experimentation, however, shows that "char" is actually > equivalent to char(1) --- it takes 5 bytes to store, even though psql's > "\d table" command lies and claims it takes only 1. Worse, the field > requires 4-byte alignment, which means if you have several of them > in a row, it's costing you 8 bytes apiece. > > Is this a documentation error, or a code bug? If not a bug, is there > any other way to store a character as a single-byte field? I'm > currently using char fields all over the place as "poor man's enumerated > type" values, and I'm rather annoyed to find that what I thought was > taking 1 byte per field is actually taking 8... Should I add this to the TODO list, that char is not char1 but has 4-byte length? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Should I add this to the TODO list, that char is not char1 but has
> 4-byte length?
Well, Tom Lockhart responded that "it's not a bug, it's a feature".
I still think it's broken --- and certainly the fact that quoting
affects the result (char and "char" act differently) is not good.
But the discussion seems to have died out without producing any
definite plan of action.
regards, tom lane
> Bruce Momjian <maillist@candle.pha.pa.us> writes: > > Should I add this to the TODO list, that char is not char1 but has > > 4-byte length? > > Well, Tom Lockhart responded that "it's not a bug, it's a feature". > I still think it's broken --- and certainly the fact that quoting > affects the result (char and "char" act differently) is not good. > But the discussion seems to have died out without producing any > definite plan of action. If we use char1 for internal tables, we should allow it externally, if only as char1. I will add it to the TODO list. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > Should I add this to the TODO list, that char is not char1 but has
> > 4-byte length?
> Well, Tom Lockhart responded that "it's not a bug, it's a feature".
> I still think it's broken --- and certainly the fact that quoting
> affects the result (char and "char" act differently) is not good.
> But the discussion seems to have died out without producing any
> definite plan of action.
Well, it is a feature, not a bug! Or at least is difficult to get
completely and transparently right given both that SQL92 has some
specific behaviors required of 'char' and 'char(1)' (they need to be
identical) and that we have a historical implementation and usage of
'char' as a one-byte-storage type.
But I'm working on reconciling pg_dump with the various ways to input
type names, and am looking at fixing code to address the specific bug
report regarding DEFAULT clauses. Some fixes will be possible with
v6.4.1, with perhaps more complete fixes available in v6.5. Give me a
few hours and I'll get back to you.
btw, it died out partly because the bug report gave an example (good)
but did not give a succinct statement of the problem (bad). I get *way*
too much e-mail on the Postgres list and a few others (I lurk on the
gnome list because they use the same sgml documentation tools) to catch
every report the way I should...
- Tom
> > Well, Tom Lockhart responded that "it's not a bug, it's a feature".
> > I still think it's broken --- and certainly the fact that quoting
> > affects the result (char and "char" act differently) is not good.
OK, I've committed changes to *both* trees prompted by the problems with
handling the single-byte character type.
One set of changes removes the double quotes from most data type fields
in pg_dump (they aren't really legal there in the SQL92 sense anyway).
pg_dump now writes "character" and "character varying" for the Postgres
internal types "bpchar" and "varchar" to be more compatible with
standard usage.
Another set of changes modifies the type matching for DEFAULT statements
to use the recently implemented implicit type coersion techniques. More
permutations of DEFAULT clauses should now be legal and handled.
Please test this stuff! Especially if you are set up to test the REL6_4
tree since I've done all testing on the main development tree.
btw, all regression tests pass on my machine.
> If we use char1 for internal tables, we should allow it externally, if
> only as char1. I will add it to the TODO list.
As what?
- Tom
> > If we use char1 for internal tables, we should allow it externally, if > > only as char1. I will add it to the TODO list. > > As what? As "char1", of course. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > > If we use char1 for internal tables, we should allow it
> > > externally, if only as char1. I will add it to the TODO list.
> > As what?
> As "char1", of course.
Oh well. Thought that there might be other solutions, that's all...
- Tom
> > > > If we use char1 for internal tables, we should allow it > > > > externally, if only as char1. I will add it to the TODO list. > > > As what? > > As "char1", of course. > > Oh well. Thought that there might be other solutions, that's all... Well, since ansi wants char to be char(1) and to be like that other char's, I don't think we have a choice but to choose another name. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026