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
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
> 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
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
>
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
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
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
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
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
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
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
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
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
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/
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
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
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
"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
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
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
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
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
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
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
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
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
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
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
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
29 matches
Mail list logo