This thread is not worth adding to TODO.detail, is it?
> "Josh Berkus" <josh@agliodbs.com> writes:
> > And, just to throw a banana peel onto the sidewalk of argument, there is
> > even a reason to keep things the way they are. [ ... ]
> > Thus there's a good reason for the database to be indecisive about
> > float/numeric decisions, and good reason for you to explicitly CAST.
>
> Indeed. However, the SQL92 spec has its mind made up: section 6.12 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, [ ... ]
>
> 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.
>
> So it's clear that for spec conformance we should cast numeric to float8
> and do the multiply in float math. (Never mind that this could result
> in loss of precision or even overflow :-( since PG's numerics actually
> have a wider range of values than float8.)
>
> A closely related issue is that SQL92 expects a literal like "1.234"
> to be considered exact numeric, not approximate, so our initial typing
> of such literals as float8 is wrong too. We'll have to fix literal
> processing as well as the float8-vs-numeric-preference issue before we'll
> have spec-compliant processing of expressions like "numericvar * 1.234".
> (And yes, there's been lots and lots of discussion about how to do that,
> too...)
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
