Re: BUG #19752: GROUP BY on a constant and a cast to a length-limited array type crashes the server while planning

пт, 9 окт. 2026 г. в 01:10, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

>
> > Skipping every GROUP BY item that contains no level-zero Var is too
> > broad. The item in that query is a Const, so it contains no Var, and
> > the commit exists to keep it a candidate. The constants that must not
> > be replaced are the other Const nodes that happen to compare equal.
>
> We might need to special-case TLEs that are identified this way.
> The basic problem is how do you tell which Consts are okay to replace,
> and what I'm saying is "none of them, except the identified TLE".
>
>
Agreed.

None of the Consts should be replaced, except the targetlist
entry that GROUP BY identified.

That entry already carries a ressortgroupref. When its expression is a
Const or Param, substitute_grouped_columns_mutator() replaces the entry
as a whole. The match is on ressortgroupref, because groupClauses may
be a copy after join alias flattening. These items are skipped in the
equal() loop, so the same value elsewhere stays a constant. Param
takes the same path as Const, since the existing code accepts the two
together.

select 1 as one group by rollup(one) order by one nulls first still
returns a null row and then 1.
select 1 as one, 1+2 as three group by rollup(one) leaves three as 3.

The reported query no longer crashes.

GROUP BY true identified the boolean constant, and the true inside
ArrayCoerceExpr.elemexpr was a different Const.

Patch attached.

--
Regards,
Rachitskiy Andrey