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

Tender Wang <tndrwang(at)gmail(dot)com> 于2026年6月29日周一 10:31写道：
>
> Hi Richard,
> I applied the v2 patch; it fixed the reported issue in [1].
> But it failed on Chengpeng Yan's reported case.
>
> SELECT x, c
> FROM (
> SELECT x, count(*) OVER (PARTITION BY x) AS c
> FROM t
> ) s
> WHERE ascii(x) = 97;
> NOTICE: using standard form "und-u-ks-level2" for ICU locale
> "@colStrength=secondary"
> CREATE COLLATION
> CREATE TABLE
> INSERT 0 2
> x | c
> -----+---
> abc | 1
> (1 row)
>

Only comparing expr's inputcollid to varcollid doesn't seem enough here.
We don't know whether the FunExpr inside uses the inputcollid; in this
case, ascii() is collation-unaware.
Now we don't have the infrastructure to know whether a function is
collation-aware.

If we find a function wrapped on the Var, we give up the qual pushed down.
We still have the optimization opportunity that if the OpExpr contains
a bare Var on one side.

--
Thanks,
Tender Wang