3 ms·
What I'm guessing here is that the column is text-biased and so what's being compared is "2" to 10, and the implicit cast is "2" > "10" because strings are comp
by BulgarianIdiot 5y ago
What I'm guessing here is that the column is text-biased and so what's being compared is "2" to 10, and the implicit cast is "2" > "10" because strings are compared char by char left to right.
In schemas, when you define a column as integer or float, input is interpreted this way WHEN POSSIBLE (i.e. with 1 and 2 it's possible, but if you pass "foo" it'll be stored as a text attribute, obviously).
What people should know with SQLite is that it's flexible about types, and stores everything you pass, but it still cares what the column type is and it affects how it interprets input.
- jolmg 5y ago> What people should know with SQLite is that it's flexible about types and flexible how. What caught me off-guard is that I thought that since the types aren't specified with .import, sqlite would behave like how it does when you create a table without specifying the types: sqlite> create table t(x); sqlite> insert into t values (1), (2); sqlite> select * from t where x < 10; 1 2 sqlite> select * from t where x > 10; But that's not the case. It behaves like the types were explicitly set as text: sqlite> create table t(x text); sqlite> insert into t values (1), (2); sqlite> select * from t where x < 10; 1 sqlite> select * from t where x > 10; 2