Fix codegen for binary functions and add fuzz test for math functions
(we need to compile `rusqlite` with `-DSQLITE_ENABLE_MATH_FUNCTIONS` in
order to bundle sqlite with math functions compiled)
Reviewed-by: Jussi Saurio (@jussisaurio)
Closes#1015
Align `substr` implementation with SQLite spec
(https://www.sqlite.org/lang_corefunc.html#substr):
> The substr(X,Y,Z) function returns a substring of input string X that
begins with the Y-th character and which is Z characters long. If Z is
omitted then substr(X,Y) returns all characters through the end of the
string X beginning with the Y-th. The left-most character of X is number
1. If Y is negative then the first character of the substring is found
by counting from the right rather than the left. If Z is negative then
the abs(Z) characters preceding the Y-th character are returned. If X is
a string then characters indices refer to actual UTF-8 characters. If X
is a BLOB then the indices refer to bytes.
Reviewed-by: Jussi Saurio (@jussisaurio)
Closes#1013
According to SQLite documentation, the way to use these instructions is
to compare the seek key to the index key as you would with the Compare
opcode. The compare opcode states:
> "Compare two vectors of registers in reg(P1)..reg(P1+P3-1) (call this
vector "A") and in reg(P2)..reg(P2+P3-1) ("B")."
In other words, we should compare the same number of columns from each,
not compare the entire keys.
This fixes a few Clickbench queries returning incorrect results, and so
closes#1009
---
Future work: support index seek keys that use multiple columns. Our
index seek is many times slower than SQLite because we're not utilizing
all the possible columns -- instead we just use the first index column
to seek and then make the rest of the comparisons as normal loop
condition expressions.
Note that IdxLE and IdxLT are currently "dead" opcodes since they were
recently introduced in #1010 but not yet utilized, as we lack support
for descending indexes
Closes#1016
According to SQLite documentation, the way to use these instructions
is to compare the seek key to the index key as you would with the
Compare opcode. The compare opcode states:
"Compare two vectors of registers in reg(P1)..reg(P1+P3-1)
(call this vector "A") and in reg(P2)..reg(P2+P3-1) ("B")."
In other words, we should compare the same number of columns from each,
not compare the entire keys.
This fixes a few Clickbench queries returning incorrect results, and
so closes#1009
---
Future work: support index seek keys that use multiple columns. Our
index seek is many times slower than SQLite because we're not utilizing
all the possible columns -- instead we just use the first index column
to seek.
I added the two opcodes as an initial step. They are pretty easy to
implement since we already have the counterparts i.e., IdxGE and IdxGT
Is there a design reason behind their omission @penberg @PThorpe92?
I noticed the same for SeekLE and SeekLT.
Reviewed-by: Jussi Saurio <jussi.saurio@gmail.com>
Closes#1010
easy implementation, sqlite claims it is a noop now
"This pragma no longer functions. It has become a no-op. The
capabilities formerly provided by PRAGMA legacy_file_format are now
available using the SQLITE_DBCONFIG_LEGACY_FILE_FORMAT option to the
sqlite3_db_config() C-language interface."
Closes#1007
Basic dump support
This is a basic support for the very useful .dump command. It doesn't
yet implement any of the dump options sqlite has, and it doesn't add
some of the logic for things like indexes, since we don't have them.
Closes#1011
This is a basic support for the very useful .dump command.
It doesn't yet implement any of the dump options sqlite has,
and it doesn't add some of the logic for things like indexes,
since we don't have them.
easy implementation, sqlite claims it is a noop now
"This pragma no longer functions. It has become a no-op. The capabilities
formerly provided by PRAGMA legacy_file_format are now available using
the SQLITE_DBCONFIG_LEGACY_FILE_FORMAT option to the sqlite3_db_config()
C-language interface."
After reading the fine print, SQLite documentation explains that `BEGIN
IMMEDIATE` and `BEGIN EXCLUSIVE` are the same thing in WAL mode:
https://www.sqlite.org/lang_transaction.html
As that's the only mode we support, let's just add code generation for
`BEGIN EXCLUSIVE`.
Fixes#1002Closes#1003
After reading the fine print, SQLite documentation explains that `BEGIN
IMMEDIATE` and `BEGIN EXCLUSIVE` are the same thing in WAL mode:
https://www.sqlite.org/lang_transaction.html
As that's the only mode we support, let's just add code generation for
`BEGIN EXCLUSIVE`.
Fixes#1002
I found invalid option while reading CONTRIBUTING.md and trying some
commands in it.
error:
```
$ cargo run --package limbo --bin limbo database.db
error: no bin target named `limbo`.
$ rustc --version
rustc 1.83.0 (90b35a623 2024-11-26)
```
ref: https://github.com/tursodatabase/limbo/blob/291637cc7120303fd7337c3
42cf5dbc9363faa85/cli/Cargo.toml#L17
Closes#995
Emit the following code sequence for `BEGIN IMMEDIATE`:
```
limbo> EXPLAIN BEGIN IMMEDIATE;
addr opcode p1 p2 p3 p4 p5 comment
---- ----------------- ---- ---- ---- ------------- -- -------
0 Init 0 4 0 0 Start at 4
1 Transaction 0 1 0 0
2 AutoCommit 0 0 0 0 auto_commit=false, rollback=false
3 Halt 0 0 0 0
4 Goto 0 1 0 0
```
Please note that SQLite emits *two* transaction instructions -- one for
main database and one for temporary tables. However, since we don't
support the latter, we only emit one transaction instruction.
