Tom Lane writes:
> (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 ...)
I think that must have been it, why else would they (implicitly) rank
floats above numerics. If we submit to that notion, then I agree with the
promotion tree you suggested.
The problem remains that upward casting will not be guaranteed to work all
the time, which is something that needs to be addressed; in potentially
unpretty ways, because not every casting decision is necessarily a linear
ladder-climb, it might be affected by other casting decisions going on in
parallel. (The workaround here could be to convert numerics that are wider
than floats to `infinity' :-)
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden