pub fn agg_table_schemas(ast: &Ast) -> Vec<AggTable>Expand description
Collect a synthetic AggTable for every relationship count aggregate in ast,
recursively (a nested aggregate under a materialized related is included). The caller
(the replica consumer / the publisher’s schema list) advertises these alongside the real
base-table schemas so the client can register + validate them.
The where tree is deliberately NOT walked. An aggregate does reach it — a having_count
parent gate is an EXISTS over a HAVING-filtered reduce — but that gate is a CLONE of a
materialized related count_as (Query::having_count requires one), and
agg_table_name hashes neither alias nor having, so it names the very table the
display aggregate already contributes here. Walking where would only re-derive a
duplicate. The gate’s own slot ships nothing: table_tree prunes it, because a
where-EXISTS slot holds witness child rows rather than the reduce’s output.