This is a first step to supporting [sqlite column
affinity](https://www.sqlite.org/datatype3.html) properly in limbo --
just adds an `affinity()` function to `Column` that can then be used
elsewhere
Closes#1030
Fix#1012
In the INSERT statement generated by dump function, if the type affinity
of the value is TEXT, replace each single quotation mark with two single
quotation marks, and wrap it with single quotation marks.
Example:
```plaintext
limbo> CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(100));
INSERT INTO users (id, name) VALUES
(1, 'Alice'),
(2, 'Bob'),
(3, 'Char''lie');
SELECT * FROM users;
1|Alice
2|Bob
3|Char'lie
limbo> .dump
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR (100));
INSERT INTO users VALUES(1,'Alice');
INSERT INTO users VALUES(2,'Bob');
INSERT INTO users VALUES(3,'Char''lie');
COMMIT;
```
Closes#1034
In the INSERT statement generated by dump function, if the type affinity
of the value is TEXT, replace each single quotation mark with two single
quotation marks, and wrap it with single quotation marks.
This PR is extracted from the sqlite fuzzing exploration effort in
https://github.com/tursodatabase/limbo/pull/1021
---
We were not evaluating constant conditions (e.g '1 IS NULL') when there
were no tables referenced in the query, because our WHERE term
evaluation was based on "during which loop" to evaluate them. However,
when there are no tables, there are no loops, so they were never
evaluated.
Closes#1023
When testing with `test-shell` the test may error and the error file
will be tracked in git. Added gitignore rule to always not track
`limbo_output.txt`
Closes#1027
We were not evaluating constant conditions (e.g '1 IS NULL')
when there were no tables referenced in the query, because
our WHERE term evaluation was based on "during which loop"
to evaluate them. However, when there are no tables, there are
no loops, so they were never evaluated.
This PR is sourced from the fuzzing exploration PR in
https://github.com/tursodatabase/limbo/pull/1021
**Adds missing support:**
Support all the same literals in WHERE clause position as in SELECT
position
Support CAST in WHERE clause position
Support FunctionCall in WHERE clause position
Support Column in WHERE clause position
Support Rowid in WHERE clause position
Support CASE in WHERE clause position
Support LIKE in SELECT position
Support Unary expressions in WHERE clause position
Support rest of the Binary expressions in WHERE clause position
Support TEXT in remainder operations
**Fix:**
Remove incorrect constant folding optimization for NULL
**Testing utils:**
Enhance sqlite fuzzer to mostly be able to work with the same set of
possible expressions in both SELECT and WHERE clause position
Closes#1024
For serial types 3 and 5 SQLite uses twos-complement representation of
24bit and 48bit widths integers. Limbo need to follow same
Reviewed-by: Jussi Saurio (@jussisaurio)
Closes#1020
This PR adds simple fuzz test with `SELECT` over data in table and fixes
bug in codegen for `AND` binary operator.
The new fuzz test resembles `logical_expression_fuzz` - but right now
Limbo do not support a lot of conditions (for example, `SELECT * FROM
users WHERE NOT deleted` will fail with `not implemented` error) - so
fuzz test written from scratch and limits `WHERE` condition structure to
the features supported right now.
Closes#1017
Fix codegen for binary functions and add fuzz test for math functions
(we need to compile `rusqlite` with `-DSQLITE_ENABLE_MATH_FUNCTIONS` in
order to bundle sqlite with math functions compiled)
Reviewed-by: Jussi Saurio (@jussisaurio)
Closes#1015
Align `substr` implementation with SQLite spec
(https://www.sqlite.org/lang_corefunc.html#substr):
> The substr(X,Y,Z) function returns a substring of input string X that
begins with the Y-th character and which is Z characters long. If Z is
omitted then substr(X,Y) returns all characters through the end of the
string X beginning with the Y-th. The left-most character of X is number
1. If Y is negative then the first character of the substring is found
by counting from the right rather than the left. If Z is negative then
the abs(Z) characters preceding the Y-th character are returned. If X is
a string then characters indices refer to actual UTF-8 characters. If X
is a BLOB then the indices refer to bytes.
Reviewed-by: Jussi Saurio (@jussisaurio)
Closes#1013
According to SQLite documentation, the way to use these instructions is
to compare the seek key to the index key as you would with the Compare
opcode. The compare opcode states:
> "Compare two vectors of registers in reg(P1)..reg(P1+P3-1) (call this
vector "A") and in reg(P2)..reg(P2+P3-1) ("B")."
In other words, we should compare the same number of columns from each,
not compare the entire keys.
This fixes a few Clickbench queries returning incorrect results, and so
closes#1009
---
Future work: support index seek keys that use multiple columns. Our
index seek is many times slower than SQLite because we're not utilizing
all the possible columns -- instead we just use the first index column
to seek and then make the rest of the comparisons as normal loop
condition expressions.
Note that IdxLE and IdxLT are currently "dead" opcodes since they were
recently introduced in #1010 but not yet utilized, as we lack support
for descending indexes
Closes#1016
