> > For numbers there is probably only the solution to invent an
> > "anynumber" generic type.
>
> Actually, I had been toying with the notion of doing the following:
>
> 1. A numeric literal is initially typed as the smallest type that will
> hold it in the series int2, int4, int8, numeric (notice NOT float8).
Yes, that sounds like a good plan for all scenarios that can follow !
> 2. Allow implicit up-coercion int2->int4->int8->numeric->float4->float8,
> but down-coercions aren't implicit except for assignment.
How about int2->int4->int8->numeric->float4->float8->numeric ?
That would also allow an upward path from float8.
> 3. Eliminate most or all of the cross-numeric-type operators
> (eg, there is no reason to support int2+int4 as a separate operator).
Yes.
> With this approach, an expression like "int4var = 42" would be initially
> typed as int4 and int2, but then the constant would be coerced to int4
> because int4=int4 is the closest-match operator. (int2=int2 would not
> be considered because down-coercion isn't implicitly invokable.)
It would fix the constants issue, yes. How about where int2col=int4col
and it's indexability of int2col though ?
> Also
> we get more nearly SQL-standard behavior in expressions that combine
> numeric with float4/float8: the preferred type will be float, which
> accords with the spec's notions of exact numeric vs.
> approximate numeric.
I do not understand the standard here.
Especially the following would seem awkward if that would switch to approximate:
set numericcol = numericcol * float4col;
Andreas