Tom Lane wrote: > "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
