Re: Proposal for resolving casting issues

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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 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