With this change, the following two queries are considered equivalent:
```sql
SELECT value FROM generate_series(5, 50);
SELECT value FROM generate_series WHERE start = 5 AND stop = 50;
```
Arguments passed in parentheses to the virtual table name are now
matched to hidden columns.
Column references are still not supported as table-valued function
arguments. The only difference is that previously, a query like:
```sql
SELECT one.value, series.value
FROM (SELECT 1 AS value) one, generate_series(one.value, 3) series;
```
would cause a panic. Now, it returns a proper error message instead.
Adding support for column references is more nuanced for two main
reasons:
- We need to ensure that in joins where a TVF depends on other tables,
those other tables are processed first. For example, in:
```sql
SELECT one.value, series.value
FROM generate_series(one.value, 3) series, (SELECT 1 AS value) one;
```
the one table must be processed by the top-level loop, and series must
be nested.
- For outer joins involving TVFs, the arguments must be treated as ON
predicates, not WHERE predicates.
In SQLite, the field equivalent to `constraint_usage` (`aConstraintUsage`
from `sqlite3_index_info`) is used to request arguments that are later
passed to the `xFilter` method. In Limbo, this behavior applies to
virtual tables, but not to table-valued functions. Currently, TVFs have
dedicated handling that passes all function arguments to the filter
method and doesn't use information provided in the `constraint_usage`
field.
This commit is a step toward unifying the handling of virtual tables and
TVFs.
We need to enumerate first and filter afterward — not the other way
around — because we later use the indexes produced by `enumerate` to
access the original `predicates` slice.
Previously, the test queries added in this commit would fail with:
thread 'main' panicked at core/schema.rs:129:34:
not implemented
stack backtrace:
0: rust_begin_unwind
at /rustc/90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf/library/std/src/panicking.rs:665:5
1: core::panicking::panic_fmt
at /rustc/90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf/library/core/src/panicking.rs:74:14
2: core::panicking::panic
at /rustc/90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf/library/core/src/panicking.rs:148:5
3: limbo_core::schema::Table::get_root_page
at ./core/schema.rs:129:34
4: limbo_core::translate::main_loop::init_loop
at ./core/translate/main_loop.rs:260:44
5: limbo_core::translate::emitter::emit_query
at ./core/translate/emitter.rs:568:5
6: limbo_core::translate::emitter::emit_program_for_select
at ./core/translate/emitter.rs:496:5
7: limbo_core::translate::emitter::emit_program
at ./core/translate/emitter.rs:187:31
8: limbo_core::translate::select::translate_select
at ./core/translate/select.rs:82:5
9: limbo_core::translate::translate_inner
at ./core/translate/mod.rs:241:13
10: limbo_core::translate::translate
at ./core/translate/mod.rs:95:17
11: limbo_core::Connection::run_cmd
at ./core/lib.rs:416:31
12: <limbo_core::QueryRunner as core::iter::traits::iterator::Iterator>::next
at ./core/lib.rs:916:22
13: limbo::app::Limbo::run_query
at ./cli/app.rs:442:27
14: limbo::app::Limbo::handle_input_line
at ./cli/app.rs:544:13
15: limbo::main
at ./cli/main.rs:51:31
16: core::ops::function::FnOnce::call_once
I am currently working on upgrading Rust to the latest version
(https://github.com/tursodatabase/limbo/pull/1807). Initially, I wanted
to address all Clippy errors in that PR, but I decided to move them into
a separate one to make it easier to review.
**Note:** In the latest version of Clippy, it is considered an error to
place variables after a comma in string formatting macros (e.g.,
`format!`), rather than inside the `{}` placeholders. That's where most
of the errors are coming from.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#1827
Although concurrency doesn't work yet (#2059), we do want to support
concurrency, and one good first step is not to make the simulator hang
forever once any connection gets a `Busy` result from the VDBE
Closes#2060
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2061
- Also added a benchmark for opening databases, the main thing that is
slowing `Database::open_file` is `parse_schema_rows`.
- `to_uppercase` was being called multiple times, leaving a relevant
mark on stack traces due to multiple allocations. `make_ascii_upper`
reuses the memory and is faster due to not handling unicode characters
(still compatible with sqlite).
- Do direct btree calls instead of creating a program for updating
`Schema` with `Schema::make_from_btree`.
- Faster type substr comparison using fixed size `u8` slices.
<img width="952" height="507" alt="image" src="https://github.com/user-
attachments/assets/0d0c52ff-05a1-431e-a93d-e333b53c0bb8" />
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2042
This inhibits ANSI color codes on non-TTY stdouts. It should fix logs
with mangled color codes such as
https://github.com/tursodatabase/turso/issues/2046.
## Result
On this branch:
<img width="1492" height="421" alt="image" src="https://github.com/user-
attachments/assets/1d281203-bda1-41c6-944e-f10dac16834e" />
If I don't pipe or redirect, on this branch, the color is displayed.
On main:
<img width="1496" height="438" alt="image" src="https://github.com/user-
attachments/assets/3844edac-dead-4655-96fb-df6ab5353021" />
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#2052
Closes#2047
the validation code was assuming that:
- if the parent has overflow cells after inserting a divider cell
- the exact divider we are validating MUST be in those overflow cells
However, this is not necessarily the case. Imagine:
- First divider gets inserted at index `n`. It is too large to fit, so
it gets pushed to `parent.overflow_cells()`. Parent usable space does
not decrease.
- Second divider gets inserted at index `n+1`. It is smaller, so it
still fits in usable space.
Hence:
Provide information to the validation function about whether the
inserted cell overflowed, and use that to find the left pointer and
assert accordingly.
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2050
the validation code was assuming that:
- if the parent has overflow cells after a inserting divider cell
- the exact divider we are validating MUST be in those overflow cells
However, this is not necessarily the case. Imagine:
- First divider gets inserted at index `n`. It is too large to fit,
so it gets pushed to `parent.overflow_cells()`. Parent usable space
does not decrease.
- Second divider gets inserted at index `n+1`. It is smaller, so it
still fits in usable space.
Hence:
Provide information to the validation function about whether the inserted
cell overflowed, and use that to find the left pointer and assert accordingly.
We can use `right_page_id` directly to perform the validation instead of
carrying a raw pointer around which might be invalidated by the time we
do the validation.
Closes#2036Closes#1991
Reviewed-by: Pere Diaz Bou <pere-altea@homail.com>
Closes#2038
I noticed on instance of the nyrkio github action was still using the
old name. Updating to nyrkio/change-detection@HEAD. All other entries
are already updaeted,
Closes#2037
We can use `right_page_id` directly to perform the validation instead of
carrying a raw pointer around which might be invalidated by the time we
do the validation.
I noticed on instance of the nyrkio github action was still
using the old name. Updating to nyrkio/change-detection@HEAD.
All other entries are already updaeted,
