Peter Eisentraut <peter_e@gmx.net> writes:
> So it would have to be more like this
> int2 -> int4 -> int8 -> numeric
> float4 -> float8 -> numeric
> This tree is "correct" in the above sense but has a number of obvious
> problems.
The most fundamental of which is that it violates SQL92: combining
exact and approximate numerics is supposed to yield approximate
(ie, float), not exact.
> float[x] + numeric would now yield numeric. The solution is making an
> explicit float8+numeric function. Okay, so at the end it's actually more
> like 8 functions, but that's a price I'd be willing to pay. (Perhaps the
> commutator mechanism could be extended to cover different types as well.)
Make that 8 functions for each and every one of the numeric operators.
I don't think that's reasonable... especially since those operators
cannot cause the overflow problem to go away. (The SQL guys probably
did not foresee people implementing NUMERIC with wider range than FLOAT
;-) ... but the fact that we did so doesn't give us license to ignore
that aspect of the spec ...)
> numeric, any int/float operations would be promoted to numeric/numeric,
> which is in any case the right thing to do.
No it isn't. See above.
regards, tom lane
