NUMERIC's transcendental functions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема NUMERIC's transcendental functions
Дата
Msg-id 9416.1032624088@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: NUMERIC's transcendental functions  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Hosed PostGreSQL Installation
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Inconsistent Conversion Names