From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | NUMERIC's transcendental functions |
Date: | 2002-09-21 16:01:28 |
Message-ID: | 9416.1032624088@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I have noticed a change in behavior following the recent changes for
casting of numeric constants. In prior releases, we got
regression=# select log(10.1);
log
------------------
1.00432137378264
(1 row)
CVS tip gives
regression=# select log(10.1);
log
--------------
1.0043213738
(1 row)
The reason for the change is that 10.1 used to be implicitly typed as
float8, but now it's typed as numeric, so this command invokes
log(numeric) instead of log(float8). And log(numeric)'s idea of
adequate output precision seems low.
Similar problems occur with sqrt(), exp(), ln(), pow().
I realize that there's a certain amount of cuteness in being able to
calculate these functions to arbitrary precision, but this is a database
not a replacement for bc(1). ISTM the numeric datatype is intended for
exact calculations, and so transcendental functions (which inherently
have inexact results) don't belong.
So proposal #1 is to rip out the numeric versions of these functions.
If you're too attached to them, proposal #2 is to force them to
calculate at least 16 digits of output, so that we aren't losing any
accuracy compared to prior behavior.
Comments?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2002-09-21 18:38:08 | Re: Inconsistent Conversion Names |
Previous Message | Tom Lane | 2002-09-21 15:13:44 | Re: Hosed PostGreSQL Installation |