1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
/// Typed error taxonomy, in three tiers that reflect *when* the problem
/// was knowable:
///
/// - [`Syntax`](QueryError::Syntax): the query text itself is malformed —
/// never reached planning/execution at all (`parser.rs`, including
/// `pest`'s own grammar failures).
/// - [`Semantic`](QueryError::Semantic): the query text parsed fine but
/// describes something structurally invalid — knowable from the query
/// alone, no data/parameters needed (an unsupported pattern shape, an
/// aggregate nested somewhere it can't be, `EXPLAIN EXPLAIN`, ...).
/// - [`Type`](QueryError::Type): only knowable once a real value (from
/// stored data or a `$parameter`) is in hand and turns out to be the
/// wrong shape (arithmetic on a non-number, indexing a non-list, a
/// `date({...})` field of the wrong type, ...).
///
/// Callers that only need "did it work" (most of this codebase) keep
/// using `Display`/`?` as before — this tiering exists for callers that
/// want to react differently to "you wrote something illegal" vs "the
/// data didn't match what the query assumed" (an application surfacing
/// user-facing messages, or `ExecutionOutcome`'s telemetry categories).