The SQLite documentation explicitly says that P1, P2, and P3 are 32-bit
signed integers. P4 is a value, and P5 is a 16-bit unsigned integer.
Although we use different types for operands, the `EXPLAIN` output
should be compatible with SQLite and, therefore, use those types.
Simple implementation for aggregation functions. The code added is
purposely so that we can add things like `CEILING(avg(n))` in the future. Aggregation function
impose a higher level of complexity that requires us to plan ahead
several things:
* simple avg: `select avg(id) from users`
* nested avg: `select ceiling(avg(id)) from users`
* avg with other columns: `select ceiling(avg(id)), * from users` (yes,
this is valid sqllite). For now I'm nullifying extra columns for
simplicity.
* avg with other agg functions: `select avg(id), sum(id) from users`.
This should be supported.
* At last -- Order By is a painful enough case to treat alone (not done
in this pr)
Signed-off-by: Pere Diaz Bou <pere-altea@hotmail.com>
SQLite special-cases `LIMIT 0` by emitting an explicit `Goto` to avoid
executing any `ResultRow` statements. We, however, hacked around this in
DecrJumpZero but also the placement of the generated instruction.
Let's follow SQLite codegen here. We still need to fix `LIMIT 0`,
though.
Introduced pragma statement parsing and update in memory of default page cache size.
There are some more "improvements" to the print insn procedure — I couldn't decide what was the preferred way in rust to do printing on different int types so I went with the stupidest I could think of at the moment.
We're storing integers into the HashMap, BTreeMap is faster because
it avoid the hash function. Furthermore, we expect only to have very few
cursors here anyway, so BTreeMap is perfect.
