Ticket Hash: | afdc5a29dc169779af2cf6581ff1bc1fed715edd | |||
Title: | Lossless conversion when casting a large TEXT number to NUMERIC is not performed | |||
Status: | Closed | Type: | Documentation | |
Severity: | Minor | Priority: | Immediate | |
Subsystem: | Unknown | Resolution: | Wont_Fix | |
Last Modified: | 2019-06-11 16:02:57 | |||
Version Found In: | ||||
User Comments: | ||||
mrigger added on 2019-06-11 14:06:08:
(text/x-fossil-wiki)
Consider the following statement: <pre> SELECT CAST('8.2250617031974513E18' AS NUMERIC); -- expected: 8225061703197451300, unexpected: 8.22506170319745e+18 </pre> I would expect that the floating-point number is parsed/converted to an INTEGER value, since the corresponding value would fit into a 64 bit integer. Instead, the value is stored as an imprecise floating-point number that, when cast back, does not yield the same value: <pre> SELECT CAST(CAST('8.2250617031974513E18' AS NUMERIC) AS INT); -- 8225061703197451264 </pre> When not using an E notation, the value is converted to an INTEGER as expected: <pre> SELECT typeof(CAST('8225061703197451300' AS NUMERIC)); -- integer </pre> The conversion also works as expected for small numbers: <pre> SELECT CAST('8.225061703197E12' AS NUMERIC); -- 8225061703197 </pre> drh added on 2019-06-11 16:02:57: (text/x-fossil-wiki) The CAST to NUMERIC documentation has been clarified at [https://www.sqlite.org/docsrc/info/7a51b32537ac7e95] in an attempt to show why this is a non-issue. |