Re: [PATCH] GROUP BY ALL

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: David Christensen <david(at)pgguru(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] GROUP BY ALL
Date: 2024-07-24 08:56:43
Message-ID: CAGECzQQP+Xx2E6HJdJ2q8sCabzR1X8DVM_T9H_4e-1-wNaAAoA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 22 Jul 2024 at 22:55, David Christensen <david(at)pgguru(dot)net> wrote:
> I see that there'd been some chatter but not a lot of discussion about
> a GROUP BY ALL feature/functionality. There certainly is utility in
> such a construct IMHO.

+1 from me. When exploring data, this is extremely useful because you
don't have to update the GROUP BY clause every time

Regarding the arguments against this:
1. I don't think this is any more unreadable than being able to GROUP
BY 1, 2, 3. Or being able to use column aliases from the SELECT in the
GROUP BY clause. Again this is already allowed. Personally I actually
think it's more readable than specifying e.g. 5 columns in the group
by, because then I have to cross-reference with columns in the SELECT
clause to find out if they are the same. With ALL I instantly know
it's grouped by all
2. This is indeed not part of the standard. But we have many things
that are not part of the standard. I think as long as we use the same
syntax as snowflake, databricks and duckdb I personally don't see a
big problem. Then we could try and make this be part of the standard
in the next version of the standard.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Anthonin Bonnefoy 2024-07-24 08:57:57 Re: Use pgBufferUsage for block reporting in analyze
Previous Message jian he 2024-07-24 08:47:15 Re: pgsql: Add more SQL/JSON constructor functions