Re: [PATCH] GROUP BY ALL

2024-08-13 Thread Greg Sabino Mullane
On Tue, Jul 23, 2024 at 9:37 AM David Christensen wrote: > I'm not married to the exact syntax of this feature; anything else short > and consistent could work if `ALL` is considered to potentially > gain a different interpretation in the future. > GROUP BY * Just kidding. But a big +1 to the w

Re: [PATCH] GROUP BY ALL

2024-07-24 Thread Ashutosh Bapat
On Tue, Jul 23, 2024 at 6:53 PM David Christensen wrote: > > On Mon, Jul 22, 2024 at 4:34 PM David G. Johnston > wrote: > > > > On Mon, Jul 22, 2024 at 1:55 PM David Christensen wrote: > >> > >> I see that there'd been some chatter but not a lot of

Re: [PATCH] GROUP BY ALL

2024-07-24 Thread Andrey M. Borodin
> On 24 Jul 2024, at 13:58, Jelte Fennema-Nio wrote: > > On Tue, 23 Jul 2024 at 15:22, Andrei Borodin wrote: >> I'd like to have GROUP BY AUTO (I also proposed version GROUP BY SURPRISE >> ME). But I wouldn't like to open pandora box of syntax sugar extensions >> which may will be incompati

Re: [PATCH] GROUP BY ALL

2024-07-24 Thread Pavel Stehule
Hi st 24. 7. 2024 v 10:57 odesílatel Jelte Fennema-Nio napsal: > On Mon, 22 Jul 2024 at 22:55, David Christensen 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 >

Re: [PATCH] GROUP BY ALL

2024-07-24 Thread Jelte Fennema-Nio
On Tue, 23 Jul 2024 at 15:22, Andrei Borodin wrote: > I'd like to have GROUP BY AUTO (I also proposed version GROUP BY SURPRISE > ME). But I wouldn't like to open pandora box of syntax sugar extensions which > may will be incompatible with future standards. > If we could have extensible grammar

Re: [PATCH] GROUP BY ALL

2024-07-24 Thread Jelte Fennema-Nio
On Mon, 22 Jul 2024 at 22:55, David Christensen 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 usef

Re: [PATCH] GROUP BY ALL

2024-07-23 Thread Peter Eisentraut
mean all entries in the SELECT list that are not aggregate functions. https://duckdb.org/docs/sql/query_syntax/groupby.html#group-by-all https://docs.databricks.com/en/sql/language-manual/sql-ref-syntax-qry-select-groupby.html#parameters https://docs.snowflake.com/en/sql-reference/constructs/gro

Re: [PATCH] GROUP BY ALL

2024-07-23 Thread Paul Jungwirth
On 7/22/24 15:43, Tom Lane wrote: Isaac Morland writes: And for when this might be useful, the syntax for it already exists, although a spurious error message is generated: odyssey=> select (uw_term).*, count(*) from uw_term group by uw_term; ERROR: column "uw_term.term_id" must appear in t

Re: [PATCH] GROUP BY ALL

2024-07-23 Thread David G. Johnston
On Tue, Jul 23, 2024 at 9:48 AM David Christensen wrote: > > Sure, not everything that makes things easier is strictly necessary; > we could require `CAST(field AS text)` instead of `::text`, Probably should have...being standard and all. Though syntactic sugar is quite different from new beha

Re: [PATCH] GROUP BY ALL

2024-07-23 Thread David Christensen
On Tue, Jul 23, 2024 at 10:57 AM Laurenz Albe wrote: > > On Tue, 2024-07-23 at 08:37 -0500, David Christensen wrote: > > My intention here was to basically be a shorthand for "group by > > specified non-aggregate fields in the select list". Perhaps I'm not > > being creative enough, but what is t

Re: [PATCH] GROUP BY ALL

2024-07-23 Thread Laurenz Albe
On Tue, 2024-07-23 at 08:37 -0500, David Christensen wrote: > My intention here was to basically be a shorthand for "group by > specified non-aggregate fields in the select list".  Perhaps I'm not > being creative enough, but what is the interpretation/use case for > anything else? :-) I am somewh

Re: [PATCH] GROUP BY ALL

2024-07-23 Thread David Christensen
On Mon, Jul 22, 2024 at 4:41 PM Isaac Morland wrote: > And for when this might be useful, the syntax for it already exists, although > a spurious error message is generated: > > odyssey=> select (uw_term).*, count(*) from uw_term group by uw_term; > ERROR: column "uw_term.term_id" must appear i

Re: [PATCH] GROUP BY ALL

2024-07-23 Thread David Christensen
sugar extensions which > may will be incompatible with future standards. > If we could have extensible grammar - I'd be happy to have a lot of such > enhancements. My top 2 are FROM table SELECT column and better GROUP BY. GROUP BY AUTO also seems fine here to me; I understand the d

Re: [PATCH] GROUP BY ALL

2024-07-23 Thread David Christensen
On Mon, Jul 22, 2024 at 5:29 PM Tom Lane wrote: > > "David G. Johnston" writes: > > On Mon, Jul 22, 2024 at 1:55 PM David Christensen wrote: > >> I see that there'd been some chatter but not a lot of discussion about > >> a GROUP BY ALL feature/

Re: [PATCH] GROUP BY ALL

2024-07-23 Thread David Christensen
On Mon, Jul 22, 2024 at 4:34 PM David G. Johnston wrote: > > On Mon, Jul 22, 2024 at 1:55 PM David Christensen 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 utilit

Re: [PATCH] GROUP BY ALL

2024-07-23 Thread Andrei Borodin
On 23 Jul 2024, at 00:40, Isaac Morland wrote:odyssey=> select (uw_term).*, count(*) from uw_term group by uw_term;ERROR:  column "uw_term.term_id" must appear in the GROUP BY clause or be used in an aggregate functionLINE 1: select (uw_term).*, count(*) from uw_term group

Re: [PATCH] GROUP BY ALL

2024-07-22 Thread Tom Lane
Isaac Morland writes: > And for when this might be useful, the syntax for it already exists, > although a spurious error message is generated: > odyssey=> select (uw_term).*, count(*) from uw_term group by uw_term; > ERROR: column "uw_term.term_id" must appear in the GROUP BY clause or be > used

Re: [PATCH] GROUP BY ALL

2024-07-22 Thread Tom Lane
"David G. Johnston" writes: > On Mon, Jul 22, 2024 at 1:55 PM David Christensen 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 IMH

Re: [PATCH] GROUP BY ALL

2024-07-22 Thread Isaac Morland
On Mon, 22 Jul 2024 at 17:34, David G. Johnston wrote: > On Mon, Jul 22, 2024 at 1:55 PM David Christensen > 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 i

Re: [PATCH] GROUP BY ALL

2024-07-22 Thread David G. Johnston
On Mon, Jul 22, 2024 at 1:55 PM David Christensen 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. > > Still need some docs; just throwing this o

[PATCH] GROUP BY ALL

2024-07-22 Thread David Christensen
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. The grammar is unambiguous, so can support this construct in lieu of the traditional GROUP BY clause. Enclosed is a patch which

Re: GROUP BY ALL

2023-01-06 Thread Andrey Borodin
On Fri, Jan 6, 2023 at 1:56 PM Bruce Momjian wrote: > Because Postgres requires GROUP BY > of all non-aggregate columns of a target list, Postgres could certainly > automatically generate the GROUP BY. However, readers of the query > might not easily distinguish function calls from aggregates, so

Re: GROUP BY ALL

2023-01-06 Thread Bruce Momjian
On Mon, Dec 19, 2022 at 05:53:46PM +0100, Vik Fearing wrote: > I think this is a pretty terrible idea. If we want that kind of behavior, > we should just allow the GROUP BY to be omitted since without grouping sets, > it is kind of redundant anyway. > > I don't know what my opinion is on that. T

Re: GROUP BY ALL

2022-12-19 Thread Vik Fearing
On 12/19/22 05:19, Andrey Borodin wrote: Hi hackers! I saw a thread in a social network[0] about GROUP BY ALL. The idea seems useful. I always was writing something like select datname, usename, count(*) from pg_stat_activity group by 1,2; and then rewriting to select datname, usename

Re: GROUP BY ALL

2022-12-19 Thread Isaac Morland
On Sun, 18 Dec 2022 at 23:30, Tom Lane wrote: > Andrey Borodin 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? > In a pure relational system, yes; but since

Re: GROUP BY ALL

2022-12-18 Thread David G. Johnston
On Sunday, December 18, 2022, Tom Lane wrote: > Andrey Borodin 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

Re: GROUP BY ALL

2022-12-18 Thread Andrey Borodin
On Sun, Dec 18, 2022 at 8:30 PM Tom Lane wrote: > > I'm not especially on board with "ALL" meaning "ALL (oh, but not > aggregates)". Yes, that's the weak part of the proposal. I even thought about renaming it to "GROUP BY SOMEHOW" or even "GROUP BY SURPRISE ME". I mean I see some cases when it's

Re: GROUP BY ALL

2022-12-18 Thread Tom Lane
Andrey Borodin 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&q

GROUP BY ALL

2022-12-18 Thread Andrey Borodin
Hi hackers! I saw a thread in a social network[0] about GROUP BY ALL. The idea seems useful. I always was writing something like select datname, usename, count(*) from pg_stat_activity group by 1,2; and then rewriting to select datname, usename, query, count(*) from pg_stat_activity group