Re: Proposal for resolving casting issues

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