On 8 Oct 2017, at 3:55pm, R Smith <rsm...@rsweb.co.za> wrote:
> SQLite's typing system is great, but you can't tell me for certain the
> predicted size of a column of integers. Some will take less bits than others,
> based on the value of the actual Integer. Inside functions SQlite will try
> interpret strings as numbers if the function expects a number and vice versa
> - very useful, but the very definition of weakly (read: Dynamically) typed
> languages. In other instances, SQLite behaves much more like
> strongly/statically typed language needing a CAST() to correctly handle
> values and the like.
I agree with everybody. SQLite is unusual in two ways: it is a weakly typed
language but one which allows (and requires) CAST. And also it uses different
amounts of storage to store different numbers.
The second one isn’t as weird as it looks when you consider other languages use
different amounts of storage to store different strings.
Meanwhile we do seem to have dealt with the concerns of the original poster.
There’s no binary XOR in SQLite. Clemens Ladisch posted a simple alternative:
> For binary values, "a XOR b" = "(a | b) - (a & b)".
sqlite-users mailing list