Re: Proposal for resolving casting issues

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

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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073