d8075aa07d
This commit turns complex `or` -- `or`s in which not all variables are unified, or in which not all arms are the same shape -- into a computed table. We do this by building a template CC that shares some state with the destination CC, applying each arm of the `or` to a copy of the template as if it were a standalone query, then building a projection list and creating a `ComputedTable::Union`. This is pushed into the destination CC's `computed_tables` list. Finally, the variables projected from the UNION are bound in the destination CC, so that unification occurs, and projection of the outermost query can use bindings established by the `or-join`. This commit includes projection of type codes from heterogeneous `UNION` arms: we compute a list of variables for which a definite type is unknown in at least one arm, and force all arms to project either a type tag column or a fixed type. It's important that each branch of a UNION project the same columns in the same order, hence the projection of fixed values. The translator is similarly extended to project the type tag column name or the known value_type_tag to support this. Review comment: clarify union type extraction. |
||
---|---|---|
.. | ||
src | ||
tests | ||
Cargo.toml | ||
README.md |
This crate turns an algebrized Datalog query into a domain-specific representation of a SQL query, and then uses mentat_sql
to turn that into a SQL string to be executed.
This subsumes both planning and query construction, because in Mentat the SQL query is effectively a query plan.