> > 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
