Bug #67136 | CONV() difference, 5.1 vs. 5.5 | ||
---|---|---|---|
Submitted: | 8 Oct 2012 19:10 | Modified: | 20 Nov 2012 13:54 |
Reporter: | Ammon Sutherland | Email Updates: | |
Status: | Not a Bug | Impact on me: | |
Category: | MySQL Server: Data Types | Severity: | S2 (Serious) |
Version: | 5.1 and 5.5 | OS: | Linux (RHEL 5 64 bit) |
Assigned to: | Tor Didriksen | CPU Architecture: | Any |
Tags: | conv, datatype, functions, regression |
[8 Oct 2012 19:10]
Ammon Sutherland
[11 Oct 2012 19:31]
Sveta Smirnova
Thank you for the report. Regression verified as described, although you badly mix data types in this query: substract from VAR_STRING value without explicit casting to numeric value.
[18 Oct 2012 12:04]
Ammon Sutherland
Not to be pushy, but is there any update to this one?
[26 Oct 2012 16:51]
Ammon Sutherland
Still just checking to see if there is any update on this, it's been over 2 weeks now without an update.
[8 Nov 2012 7:51]
Tor Didriksen
According to: http://dev.mysql.com/doc/refman/5.1/en/mathematical-functions.html#function_conv conv(N, from base, to base) Returns a *string* representation of the number N Because one of the arguments is a string, the subtraction is done in floating-point according to: http://dev.mysql.com/doc/refman/5.1/en/type-conversion.html For floating point operations, we have DBL_DIG == 15 which means maximum precision is 15 digits. floating point operations changed significantly in MySQL 5.5 due to http://dev.mysql.com/worklog/task/?id=2934 To get the correct result, cast the result of conv to a numeric type: select cast(cast(CONV('e9fd12b238e6d426',16,10) as decimal(20)) - 9223372036854775807 as signed) as a; a 7637281099758359591