2 ms·
Sure, but I think what throws people for a loop is that in SQLite, you can store text in that column: sqlite> create table example(a int); sqlite> inse
by banana_giraffe 5y ago
Sure, but I think what throws people for a loop is that in SQLite, you can store text in that column:
sqlite> create table example(a int);
sqlite> insert into example values('00123');
sqlite> insert into example values('abcdef');
sqlite> select * from example;
+--------+
| a |
+--------+
| 123 |
| abcdef |
+--------+
Not to mention, "create table example(a)" is perfectly fine, and then the '00123' survives the trip to the database and back again unchanged.
Whereas in most other RDBMS implementations this is at best a warning:
mysql> create table example(test int);
Query OK, 0 rows affected (0.06 sec)
mysql> insert into example values ('00123');
Query OK, 1 row affected (0.03 sec)
mysql> insert into example values ('abcdef');
Query OK, 1 row affected, 1 warning (0.03 sec)
mysql> select * from example;
+------+
| test |
+------+
| 123 |
| 0 |
+------+
3 rows in set (0.02 sec)
This "sometimes it's text, sometimes it's a number" property of SQLite is well documented, but can lead to some impressive "what just happened to my data?" scenarios if you're not used to it.
- em500 5y agoRight, the unique (for an RMDBS) properties of sqlite is that (1) individual values rather than columns are typed and that (2) "column types" are affinities that only affect the casting rules on insertion. But your initial example only shows standard casting behavior in common with other RMDBS implementations.