Per the sqlite docs, LIKE is case-insensitive.
> The LIKE operator does a pattern matching comparison. The operand to
the right of the LIKE operator contains the pattern and the left hand
operand contains the string to match against the pattern. A percent
symbol ("%") in the LIKE pattern matches any sequence of zero or more
characters in the string. An underscore ("_") in the LIKE pattern
matches any single character in the string. **Any other character
matches itself or its lower/upper case equivalent (i.e. case-insensitive
matching)**. Important Note: SQLite only understands upper/lower case
for ASCII characters by default. The LIKE operator is case sensitive by
default for unicode characters that are beyond the ASCII range. For
example, the expression 'a' LIKE 'A' is TRUE but 'æ' LIKE 'Æ' is FALSE.
The ICU extension to SQLite includes an enhanced version of the LIKE
operator that does case folding across all unicode characters.
Note that sqlite does not support case-insensitive comparisons of
unicode characters by default. This PR _does not_ match that behavior
currently. I can change things to not support unicode-case-
insensitivity, but as I understand it, doing so may require disable the
unicode-case feature on the regex crate, and potentially using a
`regex::bytes::Regex`, instead of a `regex::Regex`. (Basically, doing
some stuff that would not match anyone's initial assumptions about how
this would work).
Closes#333
This reverts commit e365c12ce0, reversing
changes made to 21bd1a961e. The pull request broke some tests:
```
thread 'main' panicked at core/vdbe/mod.rs:1713:72:
index out of bounds: the len is 3 but the index is 3
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
while executing
"exec {*}$command"
(procedure "evaluate_sql" line 3)
invoked from within
"evaluate_sql $sqlite_exec $sql"
(procedure "run_test" line 2)
invoked from within
"run_test $::sqlite_exec $combined_sql $combined_expected_output"
(procedure "do_execsql_test" line 5)
invoked from within
"do_execsql_test sqlite_version {
SELECT sqlite_version();
} {3.46.1}"
(file "./testing/scalar-functions.test" line 434)
invoked from within
"source $testdir/scalar-functions.test"
(file "./testing/all.test" line 16)
make: *** [Makefile:59: test-compat] Error 1
```
### sqlite
<img width="792" alt="image" src="https://github.com/user-
attachments/assets/1a9238db-d948-4583-a808-f9adfec7c534">
### limbo
<img width="809" alt="image" src="https://github.com/user-
attachments/assets/ea3e5f7e-bb3e-450d-be34-59ca00128beb">
### Changes
- Add support for `sqlite_version()` function
- Update function's explain message depending on the number of arguments
Closes#331
Closes#319
1. Allow using a column as the pattern
2. Construct LIKE regexes with `^` and `$` so that eg the string
`'foobar'` does not match the pattern `'fooba'` unless the pattern
specifically has a wildcard
3. Support function expressions as the LIKE pattern
Closes#327
This PR adds support for traversing overflow payloads and inserting them
too. The test added is a simple one and must be tested with higher
degree of stress in the future.
Closes#322
https://github.com/penberg/limbo/pull/321 recently fixed an error with
register allocation order concerning binary expressions in
`translate_condition_expr`. I noticed we had the same bug in
`translate_expr` as well, and this led into noticing that our
implementation of `Insn::Function` diverges from SQLite in that it
doesn't provide a context object that keeps track of how many arguments
the function call has.
Not having the arg count available at runtime means that e.g.:
```
do_execsql_test length-date-binary-expr {
select length(date('now')) = 10;
} {1}
```
Returned 0 instead of 1, because at runtime another register was already
allocated, and `date()` was implemented like this:
```
Func::Scalar(ScalarFunc::Date) => {
let result = exec_date(&state.registers[*start_reg..]); // all registers starting from start_reg
state.registers[*dest] = result;
state.pc += 1;
}
```
SQlite bytecode engine docs for Function say:
> Invoke a user function (P4 is a pointer to an sqlite3_context object
that contains a pointer to the function to be run) with arguments taken
from register P2 and successors. The number of arguments is in the
sqlite3_context object that P4 points to.
Accordingly, this PR implements a `FuncCtx` struct that contains a
`Func` and `arg_count` (usize).
Reviewed-by: Pere Diaz Bou <pere-altea@hotmail.com>
Closes#323
I found a bug in queries using a like function in the where clause, ex:
`SELECT first_name, last_name FROM users WHERE like('Jas%', first_name)
= 1`. That panicked with the message:
```
thread 'main' panicked at core/vdbe/mod.rs:1226:33:
internal error: entered unreachable code: Like on non-text registers
```
This was caused by an off-by-one error in the vdbe code for executing a
`ScalarFunc::Like`. However, this only happened in where-like-fn
queries. Queries using the like operator (ex: `SELECT first_name,
last_name FROM users WHERE first_name LIKE 'Jas%'`) did not have this
problem.
I did some digging around, looked at the explains for these queries from
both limbo and sqlite, and it turns out, for binary expressions, limbo
positions the arguments in the register differently, which is the
ultimate root cause of this problem.
For the where-like-fn query, before execution limbo's registers look
like this:
```
[Null, Null, Integer(1), Text("Jas%"), Text("Jason"), Null, Null]
^the rhs 1 ^pattern ^haystack str
```
Sqlite's look look something like this:
```
[Null, Null, Text("Jas%"), Text("Jason"), Integer(1), Null, Null]
^pattern ^haystack str ^the rhs 1
```
Ultimately limbo's execution of scalar like function was looking in
positions 2 and 3 always, but because we stored the right-hand-side
before the like-fn arguments, there was an off-by-one error, and the
non-text register it was finding was the `Integer(1)`.
This PR changes the binary expression translation to allocate the right-
hand-side register *after* translating the left-hand-side, fixing the
off-by-one and matching sqlite's register layout.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#321
