# v0.101.0: Exact relational state and semantic depth

> **Status:** Planned
> **Scope:** Large
> **User promise:** *"Ordinary SQL workloads remain incremental through duplicates, deletions, and repeated changes."*
> **Blocked by:** [v0.100.0](v0.100.0.md)
> **Source:** [September 2026 assessment](../plans/pg-trickle-assessment-and-pre-1.0-roadmap.md)

## Theme

Close the highest-value relational state gaps without weakening PostgreSQL
semantics or admitting an optimization before its full lifecycle is proven.

## Work

- Add durable private multiplicity state for `INTERSECT`, `INTERSECT ALL`,
  `EXCEPT`, and `EXCEPT ALL`.
- Admit a narrow DISTINCT aggregate state path only where PostgreSQL equality,
  NULL behavior, deletion, and memory bounds are proven.
- Use one lifecycle for private state generation, identity version, ownership,
  readiness, rebuild, cleanup, restore, and clone handling.
- Define numeric behavior per PostgreSQL aggregate overload and test
  high-offset, low-variance inputs plus repeated retractions.
- Add JSONB or array identity only if a real workload needs it and the release
  can define canonical equality, resource, collation, migration, and
  invalidation rules.

## Exit criteria

- [ ] Every new form has mutation-by-mutation multiset parity, including
      changes to both branches in one transaction.
- [ ] Tests cover NULLs, duplicates, last-occurrence transitions, empty groups,
      overflow, and identity-generation changes.
- [ ] Restart, clone, upgrade, and failed-refresh tests preserve or safely
      invalidate private state.
- [ ] Numeric tests meet the documented overload-specific contract.
- [ ] Each state path beats or justifies its cost against rescanning on its
      declared workload.

## Scope control

Do not add an arbitrary user-defined incremental operator API. A query form is
not supported merely because the differentiator can compile it.