Re: Proposal for resolving casting issues

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