Bug #4172 | Floating point conversion looses precision (prepared staements) | ||
---|---|---|---|
Submitted: | 16 Jun 2004 21:42 | Modified: | 4 Nov 2004 21:48 |
Reporter: | Konstantin Osipov (OCA) | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server | Severity: | S2 (Serious) |
Version: | 4.1, 5.0 | OS: | Any (All) |
Assigned to: | Konstantin Osipov | CPU Architecture: | Any |
[16 Jun 2004 21:42]
Konstantin Osipov
[17 Jun 2004 19:49]
Konstantin Osipov
The program above prints: ##################################### 123 of (1/1): test_bug4172 ##################################### Value = 112.321 Length = 7 Value via query: 112.3210144043
[10 Jul 2004 23:35]
Konstantin Osipov
Georg, the test case is not correct. The reason you're getting different results is that you request different results. When you fetch from prepared statement, you fetch a float value, and when you use floating point arithmetic in the query, result value is double. Hence difference in precision. However there are other bugs in this code which I'm now trying to fix. BTW, I'd not recomend you using float, as all MySQL arithmetic is in double, it's better to use float support is quite limited.
[19 Jul 2004 20:51]
Konstantin Osipov
bk commit - 4.1 tree (konstantin:1.1966) BUG#4172
[4 Nov 2004 21:26]
Konstantin Osipov
The client side fixed using sprintf in 4.1.7
[4 Nov 2004 21:48]
Konstantin Osipov
Additional info: Subject: bk commit - 4.1 tree (konstantin:1.2090) BUG#4172 ChangeSet 1.2090 04/11/05 00:45:41 konstantin@mysql.com +1 -0 A test case for Bug#4172 "Floating point conversion looses precision (prepared staements)": adding the test case to close the bug (the bug was fixed along with other conversion incompatibilities in 4.1.7)