The database object is a way to represent state that's shared across
multiple connections. We don't want to release that object until all
connections are closed.
EDIT: will continue iterating on these ideas, as discussed on discord.
for now, this has been changed to just enable `IORING_ENABLE_SQPOLL` by
default. This is supported sin `5.11`, and I believe the last debian
release < that reached EOL in July, so shouldn't be an issue.
Closes#557
- add creating the same table two times to the list of checked
properties as a failure property example
Reviewed-by: Pekka Enberg <penberg@iki.fi>
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#554
Suggesting adding a simple guide on how to start contributing a SQL
function.
It would be easier if I had something like this when I started
contributing to Limbo, maybe it will be for others as well.
I'm aware that this will be partly out-of-date over time due to
refactors. However, I think the gist of modifying different layers
(Parser, VDBE bytecode program,...) and how they interact with each
other stays. That part is what I hope this guide can convey to a new
contributor.
What do you think?
Closes#565
Fixes#577
With the previous implementation we weren't escaping the regex meta
characters . And in certain cases glob had a different meaning than
regex.
For e.g , the below shows a glob pattern with its regex equivalent
- `[][]` translates to `[\]\[]`
- `[^][]` translates to `[^\]\[]`
Closes#578
There is no semantic changes in this PR, the clippy command came from
@pereman2's suggestion in #542
There was more to fix than I previously thought. I originally set out to
refactor out some of the logic in `vdbe::step`, but with some actual
semantic changes. That file: `vdbe/mod.rs` is so full that it required
moving the `Insn` enum to another file, so I figured I would just put
some non-semantic changes all together so it's easier to review and get
that done first... and figured I'd fix some clippy warnings while I was
at it. Also adjusted the actions to `checkout/@v3`.
The project is obviously so early that there are going to be a decent
amount of things like unused fields or methods, which is why I was
originally not really pro clippy.. but seeing how many genuinely good
improvements it recommended, I think it's probably the right way to go.
Closes#563
I have added support for like function with escape i.e like(X,Y,Z) .
There is good opportunity to refactor/cleanup the like operations which
can be done in another PR, as I wanted to keep the changes small .
Closes#568
Fixes#552
In our construct regex function, we were not escaping the required
characters properly which was causing the failure.
Limbo output with this branch
```
limbo> select like('\%A', '\A');
1
limbo> select like('A$%', 'A$');
1
limbo> select like('%a.a', 'aaaa');
0
```
Closes#553
#560
Changes to `translate_expr` function:
* [`core/translate/expr.rs`](diffhunk://#diff-
371865d5d7b8bcaed649413c687492e61e94f21387cd9b2c47d989a033888c8bL1558-
R1560): Changed the `amount` parameter in the `Insn::Copy` instruction
from `1` to `0`.
Enhancements to the testing framework:
* [`testing/scalar-functions.test`](diffhunk://#diff-
a046d58ab24eee8207f0ce3199f8d0a609edcef9c24b8ed7f242f7a60e6c1e61R812-
R815): Added a new test `do_execsql_test_regex` to validate that the
`sqlite_version` function returns a valid output.
* [`testing/tester.tcl`](diffhunk://#diff-
316cca92d85df3f78558cc3e60d7420c1fd19a23ecf2bbea534db93ab08ea3ecR29-
R45): Introduced a new procedure `do_execsql_test_regex` to support
regex-based validation of SQL outputs.
Closes#561
### Purpose of this PR
Support for DELETE query execution planning
### Implementation Details
The main entry point for planning DELETE queries is the
`translate_delete` function. It is composed of three primary steps:
- `prepare_delete_plan`:
- Reuses the existing SELECT query's WHERE clause parsing logic to
interpret and construct the initial delete plan.
- `optimize_delete_plan`:
- eliminating BETWEEN expressions
- usage of indexes
- `emit_program_for_delete`:
- Add instructions for delete operation
I've tried to reuse existing logic(mostly on SELECT operations) as much
as I can, so that we can automatically incorporate new changes
automatically.
### Delete planning debug
I've used `println!(...)` to specify the rows to delete. Example below
<img width="374" alt="image" src="https://github.com/user-
attachments/assets/f109e1c6-6b69-43b9-bb23-4bee3a835767" />
### Bytecode compatibility
`EXPLAIN DELETE FROM users WHERE id = 1;`
<img width="1724" alt="image" src="https://github.com/user-
attachments/assets/ce2995d7-6947-493e-ad3d-224df7f4e7c2" />
`EXPLAIN DELETE FROM users WHERE id > 3`
<img width="1726" alt="image" src="https://github.com/user-
attachments/assets/ac516bd2-fe80-44c5-9a4b-8e35d574c47d" />
`EXPLAIN DELETE FROM users WHERE id < 3`
<img width="1711" alt="image" src="https://github.com/user-
attachments/assets/29d0ccba-c373-483e-bb6b-9344289cae02" />
### TODO(future works)
- Add support for `Clear` opcode
- Add test when `delete` is implemented in `Cursor`
<img width="1728" alt="image" src="https://github.com/user-
attachments/assets/28d371fc-90f5-42e5-8add-d5218f830234" />
Closes#538
