Hi all,
the exact NUMERIC datatype materializes more and more. What I
got so far are the four arithmetic base operators, all six
comparision operators and these functions:
ABS(n)
CEIL(n)
EXP(n)
FLOOR(n)
LN(n)
MOD(m,n)
ROUND(n[,scale])
SIGN(n)
SQRT(n)
TRUNC(n[,scale])
The trigonometric ones I left out for now, but since SQRT(),
EXP() and LN() work, it wouldn't be that hard to do them
later (the former produce the same results as bc(1) does -
shortly tested up to 400 digits after the decimal point).
The speed of the complex functions is IMHO acceptable. For
example EXP() is 25% better than bc(1) on small numbers but
needs up to 3 times on very big ones (999). Who ever needs
EXP(999) or more? The result is about 7.2e433! SQRT() is a
bit slow - so be it. Postgres shouldn't become a substitute
for arbitrary precision calculators.
So I think it's time now to move the stuff into the backend.
Therefor I first need a bunch of OID's (about 30 C functions,
20 SQL functions and 10 operators for now). Should I fill up
all the holes?
For the next step then I need some help in the parser. I
think it would be good to have anything that looks like a
double/float and any integer that doesn't fit into an int4
parsed into a NUMERIC, and if it really should be one of the
others type-coerced back later. This is the only way to get
rid of the single quotes for literal NUMERIC values without
the danger of loosing digits (due to double's limited
precision). But I'm not sure about all the things that might
break if doing so.
Rereading this mail I see that I forgot the aggregates. Just
some more OID's that I need :-).
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #