Peter Eisentraut <peter@eisentraut.org> writes:
> 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.
TBH, that is obvious nonsense. A subquery could contain an aggregate
function that we've already identified as being of the current query
level. Putting such a construct into the GROUP BY list would create
an invalid query (cf. checkTargetlistEntrySQL92). Similarly, putting
a window function into the GROUP BY list would create an invalid
query.
> 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.
So according to the standard, this:
select a+b, count(*) from ... group by all;
would be invalid because a+b couldn't be written directly in
GROUP BY? I can't see us rejecting that though, since we do
allow a+b in GROUP BY.
Seems like we're getting very little help from the standard as to
what this construct actually means. I suggest that we ignore the
current draft as not having been thought through quite enough yet,
and make ALL skip any tlist entries that contain_aggs_of_level
zero or contain_windowfuncs. If that means we're extending the
standard, so be it --- we've already extended GROUP BY quite a lot,
it seems.
regards, tom lane
