From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Proposal for resolving casting issues |
Date: | 2002-09-16 14:01:03 |
Message-ID: | 26452.1032184863@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-09-16 14:02:10 | Re: 7.3 Beta Schema and pg_dump |
Previous Message | Jim Buttafuoco | 2002-09-16 13:35:26 | Re: 7.3 Beta Schema and pg_dump |