Take the logical OR of the values in register P1 and P2 and store the answer in register P3. If either P1 or P2 is nonzero (true) then the result is 1 (true) even if the other input is NULL. A NULL and false or two NULLs give a NULL output.
Take the logical AND of the values in registers P1 and P2 and write the result into register P3. If either P1 or P2 is 0 (false) then the result is 0 even if the other input is NULL. A NULL and true or two NULLs give a NULL output.
## What?
- centralized Rust integration and regression tests
- no new tests added
- no tests removed
- only refactored tests into modules and common utils
## Why?
- @penberg and I have a discussion [here](https://github.com/tursodataba
se/limbo/pull/694#discussion_r1921949665) about centralizing the
integration/ regression tests so that they are not scattered around.
- this is a PR to do that and some refactor of the existing tests to
make the structure easier to navigate + add new tests in the future.
Reviewed-by: Jussi Saurio (@jussisaurio)
Reviewed-by: Preston Thorpe (@PThorpe92)
Reviewed-by: Pere Diaz Bou (@pereman2)
Closes#753
What? adding PRAGMA statements in COMPAT doc.
Why?
- each pragma is quite independent of each other.
- make it clear for contribution.
- maybe lower the bar of contributing.
Closes#760
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.
