Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think there is some confusion here. The runtime checks Andreas was
> talking about was allowing a double of 64.0 to cast to an int4 while
> disallowing 64.1 from being cast to an int4 because it is not a hole
> number.
> I am not sure doubles have enough precision to make such comparisons
> functional (NUMERIC certainly does) but that was his proposal, and he
> stated he thought the standard required it.
It seems clear to me that the standard requires us NOT to reject that.
In the explicit-cast case, SQL92 6.10 <cast specification> saith:
3) If TD is exact numeric, then
Case:
a) If SD is exact numeric or approximate numeric, then
Case:
i) If there is a representation of SV in the data type TD
that does not lose any leading significant digits after
rounding or truncating if necessary, then TV is that rep-
resentation. The choice of whether to round or truncate is
implementation-defined.
ii) Otherwise, an exception condition is raised: data exception-
numeric value out of range.
So we are *only* allowed to throw an error for overflow; having to round
is not an error condition.
In the implicit-cast case, section 9.2 Store assignment has
k) If the data type of T is numeric and there is an approxi-
mation obtained by rounding or truncation of the numerical
value of V for the data type of T, then the value of T is set
to such an approximation.
If there is no such approximation, then an exception condi-
tion is raised: data exception-numeric value out of range.
If the data type of T is exact numeric, then it is implementation-
defined whether the approximation is obtained by rounding or
by truncation.
which is different wording but seems to boil down to the same thing: the
only error condition is out-of-range.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
