Change explanation is in the code comment for `Insn::Eq`:
```
/// Jump if either of the operands is null. Used for "jump when false" logic.
/// Eg. "SELECT * FROM users WHERE id = NULL" becomes:
/// <JUMP TO NEXT ROW IF id != NULL>
/// Without the jump_if_null flag it would not jump because the logical comparison "id != NULL" is never true.
/// This flag indicates that if either is null we should still jump.
jump_if_null: bool,
```
Closes#754
Excerpt from SQLite bytecode documentation for e.g. `Lt`:
> If the SQLITE_JUMPIFNULL bit of P5 is set and either reg(P1) or
reg(P3) is NULL then the take the jump. If the SQLITE_JUMPIFNULL bit is
clear then fall through if either operand is NULL.
I didn't want to start putting these flags into a bitmask so I just
added a separate boolean. Probably for sqlite `EXPLAIN` compatibility we
should, IF we want to be exactly compatible (which we aren't anyway atm)
Closes#755
Currently, we are using the same `Parser` instance across multiple
queries (9cc9577c91). But during this
error the parser is not finalized, so parser stack is not reset, thereby
triggering the assertion at https://github.com/tursodatabase/limbo/blob/
15f7928551435458e2991dde3a76ce71e8a32057/vendored/sqlite3-
parser/third_party/lemon/lempar.rs#L663
This PR fixes the panic by calling `sqlite3ParserFinalize()` in the case
of error.
Closes https://github.com/tursodatabase/limbo/issues/742
-----------
`git bisect` FTW
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Reviewed-by: Preston Thorpe (@PThorpe92)
Closes#752
Wire pragma wal_checkpoint to checkpoint infra
- add basic support for parsing and instruction emitting `pragma
wal_checkpoint;`
- checkpoint opcode for instruction
- checkpoint execution in `virtual machine`
- cli test
Part of #696.
Before
```
limbo> pragma wal_checkpoint;
× Parse error: Not a valid pragma name
```
After
```
Enter ".help" for usage hints.
limbo> pragma wal_checkpoint;
0|0|0
```
```
Closes#694
Relates to #127. This PR is still in draft and I have a few left things
to do (tests, improve implementation), just opening it so anyone can
track this work meanwhile.
Closes#664
## Purpose of this PR
Associate jdbc's `ResultSet` with the returned values from limbo's step
function.
## Changes
### Rust
- `Java_org_github_tursodatabase_core_LimboStatement_step` now returns
an object of java's `LimboStepResult.java`
### Java
- Added `LimboStepResult.java` in order to distinguish the type of
`StepResult`(which limbo returns) and to encapsulate the interpretation
of limbo's `StepResult`
- Change `JDBC4ResultSet` inheriting `LimboResultSet` to composition.
IMO when using inheritance, it's too burdensome to fit unmatching parts
together.
- Enhance `JDBC4Statement.java`'s `execute` method
- By looking at the `ResultSet` created after executing the qury, it's
now able to determine the (boolean) result.
## Reference
- https://github.com/tursodatabase/limbo/issues/615Closes#743
#144
- The previous `changes()` function returns 1 no matter what
- Modified `changes()` and `total_changes()` to be closer to the sqlite
implementation
- Store local `n_change` counter in the `Program` struct
- Update `last_change` and `total_changes` values in `Connection`
struct on halt
- Add `change_cnt_on` flag to `Program` struct that is `true` for
insert and delete (also need later on for update)
- Added TCL tests
Closes#749
Github actions complains about the following so let's fix it:
Error: Unable to resolve action `nyrkio/github-action-benchmark@ec6fe57`, the
provided ref `ec6fe57` is the shortened version of a commit SHA, which is not
supported. Please use the full commit SHA
`ec6fe57d80fd83c83c10c6ef3f53899ce993aebb` instead.
