Module having 

HAVING clause types for the v1 getDocuments aggregate surface.

HAVING is a boolean predicate evaluated per group, exactly as in SQL. It differs from WHERE in one structural way the type system needs to reflect: the left operand is a per-group aggregate (COUNT(*), SUM(field), AVG(field)) rather than a raw row field. The right operand is always a concrete value (> 5, BETWEEN 5 AND 10, IN (5, 10, 15)).

Ranking does not live here. “Which groups score highest on the selected aggregate” is spelled with SQL’s own ordering surface — ORDER BY <selected aggregate> [ASC|DESC] LIMIT n OFFSET m — and is resolved by crate::query::drive_document_ranked_query::mode_detection. An earlier iteration of this module carried TOP(n) / BOTTOM(n) / MIN / MAX right-operands; they were removed because they duplicated ORDER BY … LIMIT with a second, non-SQL grammar that could not express an offset.

The operator set matches crate::query::WhereOperator minus STARTS_WITH (prefix matching has no meaning on a scalar aggregate result, even one that’s a string): scalar comparison, IN, and all four BETWEEN* variants all carry through.

Multi-clause HAVING (HAVING COUNT(*) > 5 AND SUM(amount) > 100) is expressed by repeating HavingClause at the request level — implicit AND, same shape as multiple where_clauses entries.

These types are shared between the wire-decoding layer (rs-drive-abci/src/query/document_query/v1/conversions.rs) and the SDK’s request builder (rs-sdk/src/platform/documents/document_query.rs) so the drive-side struct is the single source of truth for the shape.

What executes (protocol version 14+): a grouped aggregate carrying exactly one clause that bounds the aggregate the select projects, with a contiguous-range operator (=, >, >=, <, <=, the four BETWEEN* variants). It is served as a value-bounded range read of the covering ranked index’s axis secondary — see drive_document_having_query::mode_detection for the versioned grammar. Everything else the types can express remains rejected with QuerySyntaxError: multiple clauses (implicit AND would need a per-candidate post-check no executor performs), a clause on a different aggregate than the select’s, the non-contiguous operators (!=, IN), and having without group_by. Protocol version 13 and earlier reject every non-empty having, so mixed-version networks agree across the upgrade.

Structs

HavingAggregate

Aggregate operand for the left side of a HavingClause. See HavingAggregateFunction for the per-function field requirements (empty only for COUNT(*)).

HavingClause

Single HAVING <aggregate> <op> <right> clause.

Enums

HavingAggregateFunction

Aggregate function applied to a group on the left side of a HavingClause. These are the per-group aggregates whose result is the scalar / numeric value the right-side operand compares against.

HavingOperator

Comparison operator for a HavingClause. Mirrors crate::query::WhereOperator minus STARTS_WITH (prefix matching has no natural meaning against a scalar aggregate result, even a string-typed one). BETWEEN* operand semantics match WhereOperator: a 2-element list [lower, upper]; IN expects a list of candidate values.

HavingRightOperand

Right-side operand of a HavingClause: a concrete value (literal scalar, or list-shaped operand for BETWEEN* / IN).