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
#708
This PR adds basic support for the following API for defining
Aggregates, and changes the existing API for scalars.
```rust
register_extension! {
scalars: { Double },
aggregates: { MedianState },
}
#[derive(ScalarDerive)]
struct Double;
impl Scalar for Double {
fn name(&self) -> &'static str {
"double"
}
fn call(&self, args: &[Value]) -> Value {
if let Some(arg) = args.first() {
match arg.value_type() {
ValueType::Float => {
let val = arg.to_float().unwrap();
Value::from_float(val * 2.0)
}
ValueType::Integer => {
let val = arg.to_integer().unwrap();
Value::from_integer(val * 2)
}
_ => {
println!("arg: {:?}", arg);
Value::null()
}
}
} else {
Value::null()
}
}
}
#[derive(AggregateDerive)]
struct MedianState;
impl AggFunc for MedianState {
type State = Vec<f64>;
fn name(&self) -> &'static str {
"median"
}
fn args(&self) -> i32 { 1 }
fn step(state: &mut Self::State, args: &[Value]) {
if let Some(val) = args.first().and_then(Value::to_float) {
state.push(val);
}
}
fn finalize(state: Self::State) -> Value {
if state.is_empty() {
return Value::null();
}
let mut sorted = state;
sorted.sort_by(|a, b| a.partial_cmp(b).unwrap());
let len = sorted.len();
if len % 2 == 1 {
Value::from_float(sorted[len / 2])
} else {
let mid1 = sorted[len / 2 - 1];
let mid2 = sorted[len / 2];
Value::from_float((mid1 + mid2) / 2.0)
}
}
}
```
I know it's a bit more verbose than the previous version, but I think in
the long run this will be more robust, and it matches the aggregate API
of implementing a trait on a struct that you derive the relevant trait
on.
Also this allows for better registration of functions, I think passing
in the struct identifiers just feels much better than the `"func_name"
=> function_ptr`
Closes#721
When we had multiple sql statements in cli/interactive shell, we were
only running one from them as shown below. This PR fixes them.
One added benefit of this is we can add complex sql in the tcl test
files like the changes in insert.test .
sqlite3 output
```
❯ sqlite3 :memory: "select 1;select 2"
1
2
```
Limbo main branch output
```
❯ ./target/debug/limbo.exe :memory: "select 1;select 2;"
1
```
Limbos output with this PR
```
❯ ./target/debug/limbo.exe :memory: "select 1;select 2;"
1
2
```
Reviewed-by: Preston Thorpe <cory.pride83@gmail.com>
Closes#673
I believe this closes#682
```
limbo> CREATE TABLE proficient_barrett (imaginative_etrebilal BLOB,lovely_wilson BLOB);
INSERT INTO proficient_barrett VALUES (X'656E67726F7373696E675F636861636F', X'776F6E64726F75735F626F75726E65');
limbo> SELECT * FROM proficient_barrett
WHERE (
(
(
(
imaginative_etrebilal != X'6661766F7261626C655F636F726573'
OR
(imaginative_etrebilal > X'656E67726F7373696E675F6368616439')
)
AND
(
imaginative_etrebilal = X'656E676167696E675F6E6163696F6E616C'
OR
TRUE
)
)
OR
FALSE
)
AND
(
imaginative_etrebilal > X'656E67726F7373696E675F63686164F6'
OR
TRUE
)
);
engrossing_chaco|wondrous_bourne
```
@PThorpe92 I don't think we need the `parent_op` machinery at all, we
just need to not jump to the `jump_target_when_true` label given by the
parent if we are evaluating the first condition of an AND.
related: https://github.com/tursodatabase/limbo/pull/633
Reviewed-by: Preston Thorpe <cory.pride83@gmail.com>
Closes#698
