Emre Hasegeli <emre@hasegeli.com> writes:
> We can also consider turning the current float to numeric casts to
> explicit as they are causing data loss. I am not sure how much it
> would impact backwards-compatibility. The counter argument is the
> numeric to float casts being IMPLICIT. They are causing data loss for
> sure, but I believe there are different reasons to keep them as
> IMPLICIT.
FWIW, the behavior of these casts is intended to model what the SQL
standard says about the behavior of "exact numeric" vs "approximate
numeric" types. (In our implementation, the integral types plus numeric
are in the first category, float4 and float8 in the second.) The spec is
perfectly clear that you can assign an approximate numeric to an exact
numeric, or vice versa, without any explicit cast. It is also clear that
arithmetic operations combining approximate and exact are allowed without
a cast, and yield approximate results. These rules lead to our
conclusions that exact -> approximate is an implicit cast (so that the
parser will choose eg. float8 multiplication over numeric multiplication
if you write numericvar * float8var) while approximate -> exact is an
assignment cast (so that you can assign float8 to numeric without explicit
casting). If the decisions had been driven purely by "what risks silent
precision loss", no doubt we'd have done it differently ... but it's hard
to do that and still meet the letter of the spec.
regards, tom lane