Bruce Momjian <[EMAIL PROTECTED]> writes:
> Oh, OK, I had high byte meaning no header, but clear is better, so
> 00000001 is 0x01, and 00000000 is "". But I see now that bytea does
> store nulls, so yea, we would be better using 10000001, and it is the
> same size as 00000000.
I'm liking this idea more the more I think about it, because it'd
actually be far less painful to put into the system structure than the
other idea of fooling with varlena headers. To review: Bruce is
proposing a var-length type structure with the properties
first byte 0xxxxxxx ---- field length 1 byte, exactly that value
first byte 1xxxxxxx ---- xxxxxxx data bytes follow
This can support *any* stored value from zero to 127 bytes long.
We can imagine creating new datatypes "short varchar" and "short char",
and then having the parser silently substitute these types for varchar(N)
or char(N) whenever N <= 127 / max_encoding_length. Add some
appropriate implicit casts to convert these to the normal varlena types
for computation, and away you go. No breakage of any existing
datatype-specific code, just a few additions in places like
heap_form_tuple.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
