Hello,
On 2016-03-14 13:25, Clemens Ladisch wrote:
> Cezary H. Noweta wrote:
>> Is your opinion
>
> Why would my opinion matter, as opposed to what SQLite actually does?
Because, SQLite behaves in a bit strange manner, which is opposite to
extreme carefulness of SQLite in other areas. I'm trying to know if this
behavior (or not so determined behavior) is intentional. SQLite's public
domain source could be an endorsement to the official documentation, but
under condition that the code's behavior is intentional and bug free ---
this is what I am trying to lay down.
>> that ``SELECT CAST(col AS INTEGER);'' should return (not so) random
>> result set, and receiving any INTEGER should mean that a source string
>> could have trillion or more possible values?
>
> The documentation does not specify how the textual representation of an
> out-of-range integer is to be converted, so anything SQLite does can be
> considered correct.
I do not agree. Due to ``lang_expr.html#castexpr'':
``When casting a TEXT value to INTEGER, the longest possible prefix of
the value that can be interpreted as an integer number is extracted from
the TEXT value and the remainder ignored.''
Now, the algorithm is: (1) calculate value MOD 2^64; (2) return MAX(the
(1)'s value, LARGEST_INT64). It looks a bit random with bias into
LARGEST_INT64 direction.
1. Why REALs out of range are saturated to <SMALLEST_INT64,
LARGEST_INT64> range, while TEXT integers are not (which is not documented)?
2. Why REAL => INTEGER conversion is extremely accurate described
together with a previous versions' behavior and a rationale for it,
while TEXT => INTEGER conversion is not?
Pro for your consideration of correctness would be using of a textual
comparision with -SMALLEST_INT64 in ``sqlite3Atoi64()'', however the
comparision is made under certain condition that a number was exactly 18
digits long, so it could be reduced to ``return u-1>LARGEST_INT64 ? 1 :
!neg && u-1==LARGEST_INT64 ? 2 : 0;'', which, in turn, cancels any
rationales for using a textual comparision.
Maybe somebody should put ``if ( i > 19 * incr || u > LARGEST_INT64 )
{'' instead of ``if( u>LARGEST_INT64 ){'' in mentioned ``sqlite3Atoi64()''?
It would be nice to know that source STRING (or at least the leading
digits as mentioned in the doc) was perfect INTEGER after
non-distinctive number (i.e. != SMALLEST_INT64, LARGEST_INT64, 0) has
been received from CAST, would not it be?
-- best regards
Cezary H. Noweta
