NUMERIC's transcendental functions - Mailing list pgsql-hackers

From Tom Lane
Subject NUMERIC's transcendental functions
Date
Msg-id 9416.1032624088@sss.pgh.pa.us
Whole thread Raw
Responses Re: NUMERIC's transcendental functions  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Hosed PostGreSQL Installation
Next
From: Peter Eisentraut
Date:
Subject: Re: Inconsistent Conversion Names