Although all my Sqlite3 databases depend on integer division truncation and would break with your proposed change I agree that 5/2 should equal 2.5 in order to be more consistant with other databases. I can migrate my databases to use round(). But might it be possible to create a backwards compatibilty pragma to preserve the old integer division truncation behavior? Or perhaps a compile-time option?
How do intend to treat 5/2 if passed to an Sqlite function expecting an integer argument? An error? 2? 3? I would vote that it would be treated as 2 in such a case. --- [EMAIL PROTECTED] wrote: > I am proposing to make the changes outlined below in SQLite > version 3.3.0 and I am wondering if these changes will cause > any severe hardship. > > Two changes working together: > > (1) Floating point values are *always* converted into > integers if it is possible to do so without loss > of information. > > (2) Division of two integers returns a floating point > value if necessary to preserve the fractional part > of the result. > > The effect of change (1) is to combine the integer affinity > and the numeric affinity column types into a single type. > The new type is called numeric affinity, but it works like > integer affinity. Change (2) resolves Ralf Junker's > division paradox. > > The only code that I can think of that this change might > break is cases where the user is depending on the division > of two integers returning an integer result. Such code > will need to be modified to use the "round()" function > to obtain the same result. I am thinking that such code > should be very uncommon and that this change will have > minimal impact. Nevertheless, the impact is non-zero so > I will increment the minor version number as part of this > change. > > If you can think of any other adverse impact that this > change might have, please let me know. > -- > D. Richard Hipp <[EMAIL PROTECTED]> > > __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com