`BTreeTable::to_sql` makes us incompatible with SQLite by losing e.g. the original whitespace provided during the CREATE TABLE command.
For now let's fix our tests by regex-replacing every CREATE TABLE in
the entire repo to have exactly 1 space after the table name in the
CREATE TABLE statement.
I ended up hitting #1974 today and wanted to fix it. I worked with
Claude to generate a more comprehensive set of queries that could fail
aside from just the insert query described in the issue. He got most of
them right - lots of cases were indeed failing. The ones that were
gibberish, he told me I was absolutely right for pointing out they were
bad.
But alas. With the test cases generated, we can work on fixing it. The
place where the assertion was hit, all we need to do there is return
true (but we assert that this is indeed a string literal, it shouldn't
be anything else at this point).
There are then just a couple of places where we need to make sure we
handle double quotes correctly. We already tested for single quotes in a
couple of places, but never for double quotes.
There is one funny corner case where you can just select "col" from tbl,
and if there is no column "col" on the table, that is treated as a
string literal. We handle that too.
Fixes#1974
- `OP_NewRowId` now generates new rowid semi randomly when the largest
rowid in the table is `i64::MAX`.
- Introduced new `LimboError` variant `DatabaseFull` to signify that
database might be full (SQLite behaves this way returning
`SQLITE_FULL`).
Now:
```SQL
turso> CREATE TABLE q(x INTEGER PRIMARY KEY, y);
turso> INSERT INTO q VALUES (9223372036854775807, 1);
turso> INSERT INTO q(y) VALUES (2);
turso> INSERT INTO q(y) VALUES (3);
turso> SELECT * FROM q;
┌─────────────────────┬───┐
│ x │ y │
├─────────────────────┼───┤
│ 1841427626667347484 │ 2 │
├─────────────────────┼───┤
│ 4000338366725695791 │ 3 │
├─────────────────────┼───┤
│ 9223372036854775807 │ 1 │
└─────────────────────┴───┘
```
Fixes: https://github.com/tursodatabase/turso/issues/1977
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#1985
There's some kind of a bug unrelated to the feature
implemented,
which results in test different results between sqlite3 and limbo
if do_execsql_test_on_specific_db is used to get an error message content.
For example in limbo:
```sql
do_execsql_test_on_specific_db {:memory:} not_null_primary_key {
CREATE TABLE t2 (y INT PRIMARY KEY NOT NULL);
INSERT INTO t2 (y) VALUES (1);
INSERT INTO t2 (y) VALUES (NULL);
SELECT * FROM t2;
} {"Runtime error: NOT NULL constraint failed: t2.y (19)"
1} # notice the 1
```
And in sqlite3 we get
```sql
do_execsql_test_on_specific_db {:memory:} not_null_primary_key {
CREATE TABLE t2 (y INT PRIMARY KEY NOT NULL);
INSERT INTO t2 (y) VALUES (1);
INSERT INTO t2 (y) VALUES (NULL);
SELECT * FROM t2;
} {"Runtime error: NOT NULL constraint failed: t2.y (19)"} # notice the
absense of 1
```
therefore this commit rewrites tests to use do_execsql_test_any_error
instead.
- Changed `Cursor` trait to be able to get access to `root_page`
- SQLite only updates last_insert_rowid for non-schema inserts. So we check if the `InsertAwait` is not for `root_page` before
updating rowid
