On 27.09.25 15:30, Peter Eisentraut wrote:
>> Also, what about window functions in the tlist?
>
>> (I didn't stop to figure out why this isn't giving the same error, but
>> maybe it's an order-of-checks thing.) In any case: should this give
>> "window functions are not allowed in GROUP BY", or should the
>> window-function-containing tlist item be silently skipped by GROUP BY
>> ALL? Trying to make it work is surely not the right answer.
>
> Hmm, I don't know. The syntactic transformation talks about select list
> elements that "do not directly contain an <aggregate function>", but
> that can also appear as part of <window function>, so the syntactic
> transformation might appear to apply only to some types of window
> functions, which doesn't make sense to me.
>
> I don't know what a sensible behavior should be here. Maybe in this
> first patch version just reject use of GROUP BY ALL if you find any
> window functions in the select list.
The handling of window functions by GROUP BY ALL is a semi-open-item.
The code in transformGroupClause() currently says:
/*
* Likewise, TLEs containing window functions are not okay to add
* to GROUP BY. At this writing, the SQL standard is silent on
* what to do with them, but by analogy to aggregates we'll just
* skip them.
*/
if (pstate->p_hasWindowFuncs &&
contain_windowfuncs((Node *) tle->expr))
continue;
The wording of the SQL standard currently does not address that at all
(but we could fix it), which would mean that a window function ends up
in the GROUP BY ALL expansion by default.
Personally, I don't understand what the meaning of this should be.
Aggregates relate to grouping, but window functions are a different
processing phase, so that do they have to do with grouping?
I don't see any mention of using GROUP BY with window functions in our
relevant documentation, for example
https://www.postgresql.org/docs/devel/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS
https://www.postgresql.org/docs/devel/functions-window.html
Commit ef38a4d9756 added a regression test
EXPLAIN (COSTS OFF) SELECT a, COUNT(a) OVER (PARTITION BY a) FROM t1
GROUP BY ALL;
but the test table contains no data, so I don't know if this kind of
query produces interesting information. Wouldn't a more practical
query use different columns, like
SELECT a, COUNT(b) OVER (PARTITION BY a) FROM t1
?
I see that DuckDB and Oracle (the two other implementations that can be
accessed relatively freely, though there are others) each behave
differently here.
Maybe we can produce some more test cases to see what useful behaviors
should be?
