On 26.09.25 18:23, Tom Lane wrote:
> No, I think the correct behavior would have to be to descend into
> SubLinks to see if they contain any aggregates belonging to the
> outer query level.
>
> However (looks around) we do already have that code.
> See contain_aggs_of_level. (contain_agg_clause is essentially
> a simplified version that is okay to use in the planner because
> it's already gotten rid of sublinks.)
>
> What mainly concerns me at this point is whether we've identified
> aggregate levels at the point in parsing where you want to run this.
> I have a bit of a worry that that might interact with grouping.
> Presumably the SQL committee thought about that, so it's probably
> soluble, but ...
The language used in the standard at the moment is the select list
elements that "do not directly contain an <aggregate function>", where
"directly contain" is a term of art that means "contains without an
intervening instance of <subquery>, <within group specification>, or
<set function specification> that is not an <ordered set function>". So
it means not to look into subqueries.
Note that in standard SQL, the GROUP BY clause can only contain plain
column references, not expressions, so this question is kind of moot in
that context, because the query would be invalid no matter whether you
transform the GROUP BY ALL to group by the subquery or not.
For this first patch version, I suggest you reject the use of GROUP BY
ALL if you find a subquery in the select list, unless you have an
unambiguous better solution.
(It was discussed to relax this restriction, so this discussion is
useful to collect some questions related to that.)
