Re: Fix HAVING-to-WHERE pushdown with mismatched operator families

On Wed, May 27, 2026 at 8:04 AM Richard Guo <guofenglinux@gmail.com> wrote:
> Thanks for raising these points.  For partition pruning,
> match_clause_to_partition_key() already checks both collation and
> opfamily compatibility, so I don't think it has similar issues.  I'm
> not sure what is meant by "window function pushdowns", but your
> question prompted me to look around, and I did notice that pushing
> restriction clauses down into a subquery suffers from a similar
> problem, specifically, when the subquery has DISTINCT, DISTINCT ON, or
> a window PARTITION BY clause.

I think all these issues belong to the same class of bug: the planner
moves a qual clause across a grouping layer, and the result is wrong
when the qual's equivalence relation disagrees with the grouping's,
either an opfamily mismatch or a nondeterministic-collation mismatch.
This includes HAVING-to-WHERE pushdown, as well as qual pushdown into
a subquery past its DISTINCT, DISTINCT ON, window PARTITION BY, or
set-operation grouping layer.

v2 attached tries to fix the full bug class through a shared walker
expression_has_grouping_conflict that detects either kind of conflict
in an expression tree.  The walker takes a callback that maps each
Var to the grouping equality operator for its column (or InvalidOid
for non-grouping Vars).  See the commit message for details.

- Richard