RFC 017: Aggregate modifiers

[dannymeijer]

Use this issue to track InQL RFC 017, which already exists at docs/rfcs/017_aggregate_modifiers.md.

Area

• Specification (RFCs)
• Package & tests
• Documentation

Summary

RFC 017 defines aggregate modifiers for InQL: DISTINCT, aggregate-local FILTER, ordered aggregate input, and compatibility helpers such as count_if.

Motivation

Aggregate modifiers need to compose with aggregate measures without multiplying the catalog into one function per aggregate/modifier combination or silently changing results on limited backends.

Proposal sketch

The RFC models modifiers on aggregate measures rather than defining a separate function for every combination. It covers SQL-style aggregate semantics in both query-block and dataframe authoring surfaces, including diagnostics or rejection where a backend cannot preserve the required behavior.

Open design questions to resolve before Planned:

• Should count_if(null) count zero rows or follow a stricter boolean-null diagnostic rule?
• Which aggregate functions must allow ordered input in the initial modifier contract, especially listagg, percentile_cont, and percentile_disc?

Alternatives considered

The RFC rejects one function per aggregate combination, SQL-only modifier syntax, and silently ignoring unsupported modifiers on limited backends.

Impact / compatibility

This RFC affects aggregate builder APIs, query-block aggregate syntax, Prism/Substrait lowering for modifier semantics, backend support diagnostics, and aggregate documentation.

Implementation notes (optional)

Handle after RFCs 014 and 016 so modifiers are applied to registry-backed aggregate measures instead of independent helper families.

Checklist

• I checked for an existing RFC or issue covering this.
• I can describe how this impacts existing code and how to migrate (if needed).