Re: numeric precision when raising one numeric to - Mailing list pgsql-general

From Scott Marlowe
Subject Re: numeric precision when raising one numeric to
Date
Msg-id 1116613888.31821.192.camel@state.g2switchworks.com
Whole thread Raw
In response to Re: numeric precision when raising one numeric to another.  ("Florian G. Pflug" <fgp@phlo.org>)
List pgsql-general
On Fri, 2005-05-20 at 12:27, Florian G. Pflug wrote:
> Stephan Szabo wrote:
> > On Fri, 20 May 2005, John D. Burger wrote:
> >
> >
> >>I find all these statements about the near-uselessness of
> >>NUMERIC^NUMERIC to be pretty amazing.  It's fine to say, "no one seems
> >>to be asking for this, so we haven't implemented it yet", but, c'mon,
> >>folks, Postgres gets used for more than "business cases".
> >
> > If people don't see the use of a function they aren't going to implement
> > it.  In addition, there is a small, but non-zero cost to adding a
> > function/operator to the system (in the cost to maintain it at the very
> > least) and if the general belief is that the function or operator is
> > useless or nearly useless then it simply may not be worth adding.
>
> It's not only useless, it's dangerous. As far as I know, numeric
> _guarantees_ the result of an operation to be correct to the last digit.

Actually, not so according to the spec.  The spec makes it clear that
the precision of multiplication is implementation defined, and the scale
is S1+S2.  For division both are implementation defined.

Further, it is more dangerous, to me, to coerce a power(numeric,numeric)
function to float with no warning or error that precision HAS been lost,
than to output it as numeric with as much precision as can be had, or as
the user wants / specifies.

> This is _impossible_ to achieve in the general case (think 2^(1/2)) -
> and therefor, there should be no pow(numeric, numeric).

I would just say to limit it to whatever the proper scale should be.
Now, what the scale should be, there's the real issue.

But just chopping off all the

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: numeric precision when raising one numeric to another.
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Inherited constraints and search paths