Re: [PATCH] GROUP BY ALL - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: [PATCH] GROUP BY ALL
Date
Msg-id CAExHW5tn_Bk1iFOWtmr9VsbjueTDM13O98gH8MrqQ8KnOs2MmA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] GROUP BY ALL  (David Christensen <david@pgguru.net>)
List pgsql-hackers
On Tue, Jul 23, 2024 at 6:53 PM David Christensen <david@pgguru.net> wrote:
>
> On Mon, Jul 22, 2024 at 4:34 PM David G. Johnston
> <david.g.johnston@gmail.com> wrote:
> >
> > On Mon, Jul 22, 2024 at 1:55 PM David Christensen <david@pgguru.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.
> >>
> >> Still need some docs; just throwing this out there and getting some feedback.
> >>
> >
> > I strongly dislike adding this feature.  I'd only consider supporting it if it was part of the SQL standard.
> >
> > Code is written once and read many times.  This feature caters to the writer, not the reader.  And furthermore
usageof this is prone to be to the writer's detriment as well. 
>
> I'd say this feature (at least for me) caters to the investigator;
> someone who is interactively looking at data hence why it would cater
> to the writer.  Consider acquainting yourself with a large table that
> has a large number of annoying-named fields where you want to look at
> how different data is correlated or broken-down.  Something along the
> lines of:

To me this looks like a feature that a data exploration tool may
implement instead of being part of the server. It would then provide
more statistics about each correlation/column set etc.

--
Best Wishes,
Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: warning: dereferencing type-punned pointer
Next
From: Justin Pryzby
Date:
Subject: Re: pg_upgrade failing for 200+ million Large Objects