Re: WIP Patch for GROUPING SETS phase 1 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP Patch for GROUPING SETS phase 1
Date
Msg-id 4652.1408730562@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP Patch for GROUPING SETS phase 1  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: WIP Patch for GROUPING SETS phase 1
Re: WIP Patch for GROUPING SETS phase 1
Re: WIP Patch for GROUPING SETS phase 1
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Aug 21, 2014 at 2:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Well, if there are any extant applications that use that exact phrasing,
>> they're going to be broken in any case.  That does not mean that we have
>> to break every other appearance of "cube".  I think that special-casing
>> appearances of cube(...) in GROUP BY lists might be a feasible approach.

> Not really.  As pointed out downthread, you can't distinguish "cube"
> from CUBE.  We could fix that with a big enough hammer, of course, but
> it would be a mighty big hammer.

I'm not convinced of that; I think some creative hackery in the grammar
might be able to deal with this.  It would be a bit ugly, for sure, but
if it works it would be a localized fix.  Meanwhile, I don't believe
that it's going to be possible to rename the cube extension in any way
that's even remotely acceptable for its users ("remotely acceptable"
here means "pg_upgrade works", never mind what's going to be needed
to fix their applications).  So the proposal you are pushing is going
to result in seriously teeing off some fraction of our userbase;
and the argument why that would be acceptable seems to boil down to
"I think there are few enough of them that we don't have to care"
(an opinion based on little evidence IMO).  I think it's worth investing
some work, and perhaps accepting some ugly code, to try to avoid that.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: WIP Patch for GROUPING SETS phase 1
Next
From: Tomas Vondra
Date:
Subject: Re: 9.5: Better memory accounting, towards memory-bounded HashAgg