Re: Proposal for resolving casting issues - Mailing list pgsql-hackers

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> I think the following three states may enable a closer match to an actually 
> desired (Peter said mandated by SQL99) behavior.

> 1. okay as implicit cast in expression or assignment
> 2. okay as implicit cast in expression or assignment but needs runtime check
>     (precision loss possible)
> 3. okay only as explicit cast (precision loss possible)

The runtime checks are there already, eg

regression=# select 123456789::int4::int2;
ERROR:  i4toi2: '123456789' causes int2 overflow

However this does not help us much; the critical point is that if we
want function overloading to work in a sane fashion, we have to prefer
up-conversions to down-conversions *at parse time*, at least for the
operands of functions and operators (which is what I meant by "in
expressions").  Runtime checks are irrelevant to this problem.

> Regarding the "isExplicit": I think a closer match would be an output
> argument "PrecisionInfo" enum(ok, precision loss, [conversion failed
> ?]).

I'm not planning to add output arguments to fix this problem ;-)

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

2. Allow implicit up-coercion int2->int4->int8->numeric->float4->float8,
but down-coercions aren't implicit except for assignment.

3. Eliminate most or all of the cross-numeric-type operators (eg, there
is no reason to support int2+int4 as a separate operator).

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.)  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 think this solves most or all of our problems with poor type choices
for numeric literals, but it still needs thought --- I'm not suggesting
we shoehorn it into 7.3.  In particular, I'm not sure whether the
current preferred-type arrangement (namely, numeric and float8 are both
preferred types for the numeric category) would need to change.

> There are also tons of "unsigned char vs signed char" warnings in
> current mb sources :-( 

Yeah, I know :-( ... I see 'em too when using HPUX' vendor compiler.
We ought to clean that up someday.
        regards, tom lane