Re: AW: type conversion discussion

Tom Lane writes:

> perhaps we want
>
> int2 -> int4 -> int8 -> numeric -> float8
> float4 -> float8

In a parallel email you mentioned that your promotion tree idea will give
the system well-understood (single) inheritance semantics, with which I
agree 100%. But that is only true if the upward conversion always works,
which it won't because not every numeric "is-a" float8, and strictly
speaking, neither is int8. This is unclean at best, but might even cause
genuine failures if some promotion metric decided on a float8 function
over a numeric function because it would generate the "least casting" on
the other function attributes.

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.

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.)

Incidentally, this would also enable some cases to work that wouldn't now,
e.g. if N is a numeric outside the range of float8 and F is some float8,
then N - F would currently fail, but it need not, depending on how it's
implemented.

The other problem is that integers would never implicitly be promoted to
floats. This is sensible behaviour from a numerical analysis point of view
but probably not acceptable for many. However, given that there is
numeric, any int/float operations would be promoted to numeric/numeric,
which is in any case the right thing to do. The only thing is to provide
numeric functions.

The alternative is to use a non-tree lattice for type promotion

- float4 -- float8 -
/ / \
int2 --- int4 ---- int8 ----- numeric

but that would introduce a world of problems which we probably best avoid
(as long as possible).

> That's still not entirely satisfactory because simple examples like
>
> WHERE float4var < 4.4;
>
> won't be done the way we want: the constant will promote to float8
> and then you'll get float4var::float8 < 4.4::float8 which is not
> able to use a float4 index.

Could this do it?

unknownnumeric -> float4 -> float8 -> numeric

(Assuming `unknownnumeric' only represents literals with decimal points.
Others should probably be the "best fit" integer type.)

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden