For what it is worth
I would NOT be in favor of this change. As was discussed in the original
post this would be NON-STANDARD behavior. The SQL-99 spec says that integer
math remains an integer.
The only time I would like an integer to return a "real" result is if that
integer is stored in a field of type real, then all operations on that
number should return a "real" result.
I understand the reasons for "int"s being stored as an "int" in a "real"
column, but the change I would prefer is for it to act as a "real" if stored
in a "real" column, otherwise it should act as it currently does.
Thanks for asking for opinions before making the change
Preston
From: [EMAIL PROTECTED]
Reply-To: sqlite-users@sqlite.org
To: sqlite-users@sqlite.org
Subject: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
Date: Tue, 01 Nov 2005 08:59:53 -0500
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]>
