Gregory Stark wrote:
Case 2) Solving this is quite difficult without introducing major performance
problems or security holes. The one approach we have that's practical right
now is introducing special data types such as the oft-mentioned "char" data
type. "char" doesn't have quite the right semantics to use as a transparent
substitute for CHAR but we could define a CHAR(1) with exactly the right
semantics and substitute it transparently in parser/analyze.c (btw having
two files named analyze.c is pretty annoying). We could do the same with
NUMERIC(a,b) for sufficiently small values of a and b with something like
D'Arcy's CASH data type (which uses an integer internally).
Didn't we discuss a problem with using CHAR(n), specifically that the
number of bytes required to store n characters is variable? I had
suggested making an ascii1 type, ascii2 type, etc. Someone else seemed
to be saying that should be called bytea1, bytea2, or perhaps with the
parenthesis bytea(1), bytea(2). The point being that it is a fixed
number of bytes.
The problem with defining lots of data types is that the number of casts
and cross-data-type comparisons grows quadratically as the number of data
types grows. In theory we would save space by defining a CHAR(n) for
whatever size n the user needs but I can't really see anything other than
CHAR(1) being worthwhile. Similarly a 4-byte NUMERIC substitute like CASH
(with full NUMERIC semantics though) and maybe a 2-byte and 8-byte
substitute might be reasonable but anything else would be pointless.
Wouldn't a 4-byte numeric be a "float4" and an 8-byte numeric be a
"float8". I'm not sure I see the difference. As for a 2-byte floating
point number, I like the idea and will look for an ieee specification
for how the bits are arranged, if any such ieee spec exists.
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend