Re: casts and conversions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>
Cc: Craig Longman <craigl(at)begeek(dot)com>, PostgreSQL SQL List <pgsql-sql(at)postgresql(dot)org>
Subject: Re: casts and conversions
Date: 2001-06-18 14:21:52
Message-ID: 1696.992874112@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

"Josh Berkus" <josh(at)agliodbs(dot)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

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Itai Zukerman 2001-06-18 14:30:39 Inheritance: Performance & Indexes
Previous Message Caroline 2001-06-18 08:50:01 database encryption