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

Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> writes:
> пт, 9 окт. 2026 г. в 00:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> Yeah, that's nasty, and what's nastier is that even non-crash cases
>> might result in seriously wrong answers. We shouldn't be replacing
>> constant subexpressions by group Vars ever. I'm inclined to think
>> that GROUP BY items should not be candidates for this
>> search-and-replace unless they contain at least one level-zero Var.
>> But maybe that's too simplistic?

> We should still replace the grouped constant itself. Bisect puts the
> crash at f5050f795ae ("Mark expressions nullable by grouping sets"),
> whose parent 247dea89f76 does not crash. 247dea89f76 returns on Const
> before equal(). f5050f795ae moves that return to after equal(), and
> the comment says why. A GROUP BY constant is no longer constant after
> the grouping step. The regress query added in that commit is

> select 1 as one group by rollup(one) order by one nulls first;

I think that's different: the "group by one" should identify the
first TLE and nothing else. Otherwise we have insanities like

select 1 as one, 1+2 as three group by rollup(one)

affecting both columns. (I see that it does not, right now,
but it's hard to argue why not if you think replacing constants
is okay.)

> 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".

regards, tom lane