On Wed, May 6, 2026 at 9:58 AM SATYANARAYANA NARLAPURAM <[email protected]> wrote: > It appears HAVING-to-WHERE pushdown is still wrong with CASE and > nondeterministic > collations. The shorthand CASE expression bypasses the new collation-conflict > detector, > so the HAVING clause gets pushed to WHERE, filtering rows before > grouping and silently changing aggregate results.
Right. For simple CASE (CaseExpr with a non-NULL arg), parse analysis builds each WHEN as OpExpr(CaseTestExpr op val), where CaseTestExpr is a placeholder for the arg, while the actual arg sits at cexpr->arg, outside the OpExpr that carries the comparison's inputcollid. A GROUP Var at cexpr->arg is therefore visited without the WHEN's inputcollid on the stack. So the conflict fails to be detected, and the HAVING clause is incorrectly pushed to WHERE. > My understanding is shallow here, attached a draft patch that adds a CaseExpr > branch to > having_collation_conflict_walker() mirroring the existing RowCompareExpr > special case. Patch includes the tests. Please take a look. This patch is on the right track. I didn't like how the stack was restored after walking cexpr->arg; list_truncate fits better there. The comments also needed some tightening. I've made those adjustments, pushed, and back-patched. - Richard
