QueryExpr represents filters three different ways (Scan.predicates, Filter.pred, Aggregate.having)

[milindsrivastava1997]

Summary

QueryExpr currently has three separate places a filter predicate can live:

• Scan.predicates: Vec<Predicate> — row-level filters pushed all the way down to a base scan
• Filter.pred: Predicate — a standalone node for predicates a scan can't absorb (e.g. a post-aggregate column)
• Aggregate.having: Option<Predicate> — an optional post-aggregation filter predicate

(docs/pre-asap-ir.md, Scan/Filter/Aggregate sections)

Raised in PR #180 review:

• docs: re-doing documentation #180 (comment) — "In scan there is a predicates, while in filter there is another."
• docs: re-doing documentation #180 (comment) — "So Filter is Having?"

Open question

Worth discussing whether Scan.predicates and Aggregate.having should be removed in favor of a single Filter node wrapping the scan/aggregate, at least until there's a concrete need (e.g. predicate pushdown) that requires filters to live directly on those nodes.

[zzylol]

Related open work

• Umbrella for SQL HAVING population in SQL front end never populates Aggregate.having from a real HAVING clause #201 and the canonical pushdown invariant in Enforce Filter -> Aggregate.having pushdown as a canonicalization invariant #204.
• Broader duplicate IR-shape cleanup is tracked separately by QueryExpr has duplicate relational/scalar-language shapes for the same semantics (Scalar/Literal, BinaryOp/Compare/Arith) #220.