Repository navigation
Conversation
`let q = materialized (...)`, `with t as materialized (...)`, and `values materialized (...)` all run their query once with a single null value as input when first evaluated, cache the output, and produce that output for subsequent evaluations.
| ``` | ||
| materialized ( <query> ) | ||
| ``` | ||
| A materialized subquery is evaluated just once and receives a single `null` |
There was a problem hiding this comment.
"is evaluated just once and returns the initial result on each subsequent invocation"
... "a materialized subquery has no access to the expression context in which it is evaluated... the body of the subquery has no parent operator and like all such queries, its input is a single null value"
^^^ I'm not proposing this exact wording... just this direction
|
|
||
| To create a query that can operate on its input, declare an [operator](operators.md). | ||
|
|
||
| With `materialized`, the query is evaluated once, its output is cached, |
There was a problem hiding this comment.
I would leave out the "cache" concept as that is mechanism leaking into the semantic definition here
|
|
||
| type MaterializedDef struct { | ||
| Kind string `json:"kind" unpack:""` | ||
| Name string `json:"name"` |
There was a problem hiding this comment.
Why names? They don't appear in the user facing model. Like functions, it seems like they should be a slice that is ref'd by slot in the slice.
There was a problem hiding this comment.
Hmm maybe the names relate to the querydecl name? They can't live in a flat table because they are lexically scoped.
| } | ||
| MaterializedRefOp struct { | ||
| Kind string `json:"kind" unpack:""` | ||
| Name string `json:"name"` |
There was a problem hiding this comment.
Name -> Slot ?
(see other comment)
| / Map | ||
| / SQLTimeExpr | ||
| / Literal | ||
| / MATERIALIZED __ "(" __ expr:SubqueryExpr __ ")" { |
There was a problem hiding this comment.
Materialized should work for array query too. The PEG rules could be improved by sharing the def of a subquery between expr and let, e.g., create a Materializable rule defined as
OptMaterialized __ "(" __ body:Query __ ")"
/ OptMaterialized __ "[" __ body:Query __ "]"
let q = materialized (...),with t as materialized (...), andvalues materialized (...)all run their query once with a single null value as input when first evaluated, cache the output, and produce that output for subsequent evaluations.