Re: numeric precision when raising one numeric to another.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
Cc: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: numeric precision when raising one numeric to another.
Date: 2005-05-20 17:03:08
Message-ID: 26210.1116608588@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-patches

"Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> Why are we allowing implicit casts from numeric to floating point?

Because the SQL spec requires it.

2) If the data type of either operand of a dyadic arithmetic op-
erator is approximate numeric, then the data type of the re-
sult is approximate numeric.

It doesn't say to throw an error for mixed-type arithmetic.

Now it also says

1) If the data type of both operands of a dyadic arithmetic opera-
tor is exact numeric, then the data type of the result is exact
numeric, ...

which you could take as requiring us to provide numeric equivalents of
every floating-point operator, but I don't find that argument very
convincing for operations that are inherently not going to give exact
results. The spec demands exact results from addition, subtraction,
and multiplication, but as soon as you get to division they punt; let
alone transcendental functions.

But having said that, I don't have a problem with putting in a
pg_operator entry for numeric_power. And if someone wants to improve
the scale factor calculations therein, go for it. But so far there's
been an extremely low signal-to-noise ratio in this thread ...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Robert Treat 2005-05-20 17:17:50 Re: How can I write trigger on a columns insert/update?
Previous Message Jim C. Nasby 2005-05-20 16:59:35 Re: materialized view

Browse pgsql-patches by date

  From Date Subject
Next Message Jim C. Nasby 2005-05-20 17:22:33 Re: numeric precision when raising one numeric to another.
Previous Message Jim C. Nasby 2005-05-20 16:49:20 Re: numeric precision when raising one numeric to another.