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
This pr adds a new crate to increase expressivity of tests with complex
things like btree node splitting.
To run tests:
```bash
cd core_tester
cargo test test_sequential_write -- --nocapture
```
This prs improves btree balancing with simple page splitting and some
minor refactors.
Closes#316
This PR adds a regex cache to `ProgramState` so that we ca re-use
already constructed regexes while processing LIKE expressions. I didn't
find anywhere else that seemed like a good fit to put an execution-time
only cache like this, so let me know if there's a better spot.
To best match sqlite, I added the constant mask into the `Function`
instruction (this indicates whether the first argument to the function
was determined to be constant at compile time), and decide whether to
use the cache based on its value. I've left the value for
`constant_mask` as 0 on every other kind of `Function` instruction. That
seemed to be the safest choice, as that appears to be what has been
implicitly done up to this point. Happy to change that if you'd advise
otherwise.
Fixes#168Closes#320
