Re: Proposal for resolving casting issues

Tom Lane wrote:
> "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.

I think there is some confusion here. The runtime checks Andreas was
talking about was allowing a double of 64.0 to cast to an int4 while
disallowing 64.1 from being cast to an int4 because it is not a hole
number.

I am not sure doubles have enough precision to make such comparisons
functional (NUMERIC certainly does) but that was his proposal, and he
stated he thought the standard required it.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073