Re: numeric precision when raising one numeric to another.

Why are we allowing implicit casts from numeric to floating point?
Doesn't that violate the principle of not doing any implicit casts that
would potentially drop precision? It seems that about half the arguments
here are related to getting unexpected or inaccurate results, presumably
from the implicit cast; if it was removed at least then people would
know their results might be imprecise, where as now there's no
indication of that at all.

On Wed, May 18, 2005 at 05:42:28PM -0400, Tom Lane wrote:
> Scott Marlowe <smarlowe(at)g2switchworks(dot)com> writes:
> > It appears from checking the output of exponentiation of one numeric to
> > another, the output is actually in floating point. Is this normal and /
> > or expected?
>
> Yes, seeing that the only ^ operator we have is float8.
>
> regression=# \do ^
> List of operators
> Schema | Name | Left arg type | Right arg type | Result type |
> Description
> ------------+------+------------------+------------------+------------------+----------------------
> pg_catalog | ^ | double precision | double precision | double precision | exponentiation (x^y)
> (1 row)
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"