79fa0994b3
This version removes nalexander's lovely matrix code. It turned out that scalar and tuple bindings are sufficiently different from coll and rel -- they can directly apply as values in the query -- that there was no point in jumping through hoops to turn those single values into a matrix. Furthermore, I've standardized us on a Vec<TypedValue> representation for rectangular matrices, which should be much more efficient, but would have required rewriting that code. Finally, coll and rel are sufficiently different from each other -- coll doesn't require processing nested collections -- that my attempts to share code between them fell somewhat flat. I had lots of nice ideas about zipping together cycles and such, but ultimately I ended up with relatively straightforward, if a bit repetitive, code. The next commit will demonstrate the value of this work -- tests that exercised scalar and tuple grounding now collapse down to the simplest possible SQL. |
||
|---|---|---|
| .. | ||
| src | ||
| tests | ||
| Cargo.toml | ||
| README.md | ||
This crate turns a parsed query, as defined by the query crate and produced by the query-parser crate, into an algebrized tree, also called a query processor tree.
This is something of a wooly definition: a query algebrizer in a traditional relational database is the component that combines the schema — including column type constraints — with the query, resolving names and that sort of thing. Much of that work is unnecessary in our model; for example, we don't need to resolve column aliases, deal with table names, or that sort of thing. But the similarity is strong enough to give us the name of this crate.
The result of this process is traditionally handed to the query optimizer to yield an execution plan. In our case the execution plan is deterministically derived from the algebrized tree, and the real optimization (such as it is) takes place within the underlying SQLite database.