Re: Fix GROUP BY ALL handling of ORDER BY operator semantics

> On Jul 15, 2026, at 01:08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> Ack. Another case I am a bit confused by is:
>
>> postgres=# create table t (a integer);
>> CREATE TABLE
>> postgres=# select 1 as x from t group by ();
>> x
>> ---
>> 1
>> (1 row)
>
>> postgres=# select 1 as x from t group by all;
>> x
>> ---
>> (0 rows)
>
>> Shouldn't those two queries yield the same result, or am I missing something
>> obvious?
>
> I might be undercaffeinated still, but I think those are both correct.
> "GROUP BY ()" has similar effects to use of an aggregate or HAVING
> clause: it forces the table scan's results to be combined into a
> single grouped row. But you get a grouped row even if the table is
> empty. The second case is equivalent to "select 1 as x from t group
> by x", and this is different because it will produce a grouped row
> only if the table isn't empty. (The fact that the grouping expression
> is a constant doesn't change the rule.) Not one of SQL's more
> consistent behaviors perhaps, but I believe it's all per spec.
>
> regards, tom lane

Thanks for all the comments. I was trying to target the bug fix for v19, so I kept the scope narrow. It looks like I don’t need to revise the current patch for now.

I have no objection to reverting GROUP BY ALL from v19. If the original feature author wants to rework the feature following Tom suggested direction, please go ahead. Otherwise, if people think it would be useful, I can try to work on it for v20.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/