Bruce Momjian <pgman@candle.pha.pa.us> 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
significantdigits 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
truncationof the numerical value of V for the data type of T, then the value of T is set to
suchan approximation.
If there is no such approximation, then an exception condi- tion is raised: data
exception-numericvalue out of range.
If the data type of T is exact numeric, then it is implementation- defined whether the
approximationis 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