numeric hierarchy again (was Re: floor function in 7.3b2)

Neil Conway <neilc(at)samurai(dot)com> writes:
> Sorry, I missed much of the casting discussion -- but is there a
> reason why we can't cast from float8 -> numeric implicitely? IIRC the
> idea was to allow implicit casts from lower precision types to higher
> precision ones.

The implicit casting hierarchy is now

int2 -> int4 -> int8 -> numeric -> float4 -> float8

Moving to the left requires an explicit cast (or at least an assignment
to a column). I know this looks strange to someone who knows that our
numeric type beats float4/float8 on both range and precision, but it's
effectively mandated by the SQL spec. Any combination of "exact" and
"inexact" numeric types is supposed to yield an "inexact" result per
spec, thus numeric + float8 yields float8 not numeric. Another reason
for doing it this way is that a numeric literal like "123.456" can be
initially typed as numeric, and later implicitly promoted to float4 or
float8 if context demands it. Doing that the other way 'round would
introduce problems with precision loss. We had speculated about
introducing an "unknown_numeric" pseudo-type to avoid that problem, but
the above hierarchy eliminates the need for "unknown_numeric". We can
initially type a literal as the smallest thing it will fit in, and then
do implicit promotion as needed. (7.3 is not all the way there on that
plan, but 7.4 will be.)

regards, tom lane