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
