| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrey Borodin <amborodin86(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: GROUP BY ALL |
| Date: | 2022-12-19 04:45:58 |
| Message-ID: | CAKFQuwZQojxzMf3LYiNOO0dexn030tveM2K2_Qi8b0tud_CM2g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sunday, December 18, 2022, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andrey Borodin <amborodin86(at)gmail(dot)com> writes:
> > I saw a thread in a social network[0] about GROUP BY ALL. The idea seems
> useful.
>
> Isn't that just a nonstandard spelling of SELECT DISTINCT?
>
> What would happen if there are aggregate functions in the tlist?
> I'm not especially on board with "ALL" meaning "ALL (oh, but not
> aggregates)".
>
>
IIUC some systems treat any non-aggregated column as an implicit group by
column. This proposal is an explicit way to enable that implicit behavior
in PostgreSQL. It is, as you note, an odd meaning for the word ALL.
We tend to not accept non-standard usability syntax extensions even if
others systems implement them. I don’t see this one ending up being an
exception…
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-12-19 05:42:13 | Simplifications for error messages related to compression |
| Previous Message | Andrey Borodin | 2022-12-19 04:40:00 | Re: GROUP BY ALL |