Re: GSets: Fix bug involving GROUPING and HAVING together - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: GSets: Fix bug involving GROUPING and HAVING together
Date
Msg-id 87si8rqba3.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to GSets: Fix bug involving GROUPING and HAVING together  (Jeevan Chalke <jeevan.chalke@enterprisedb.com>)
Responses Re: GSets: Fix bug involving GROUPING and HAVING together
Re: GSets: Fix bug involving GROUPING and HAVING together
List pgsql-hackers
>>>>> "Jeevan" == Jeevan Chalke <jeevan.chalke@enterprisedb.com> writes:
Jeevan> Basically, when we have only one element in GROUING SETS, weJeevan> are assuming it as a simple GROUP BY with
onecolumn. Due toJeevan> which we are ending up with this error.
 
Jeevan> If we have ROLLUP/CUBE or GROUPING SETS with multiple elements,Jeevan> then we are not getting this error.

There's two issues here. One you correctly identified, which is that
contain_agg_clause() should be true for GroupingFuncs too.

The other is that in subquery_planner, the optimization of converting
HAVING clauses to WHERE clauses is suppressed if parse->groupingSets
isn't empty. (It is empty if there's either no group by clause at all,
or if there's exactly one grouping set, which must not be empty, however
derived.) This is costing us some optimizations, especially in the case
of an explicit GROUP BY () clause; I'll look into this.

In the meantime your patch looks OK (and necessary) to me.
Jeevan> The side effect is that, if we have plain group by clause, thenJeevan> too we can use GROUPING in HAVING
clause.But I guess it isJeevan> fine.
 

GROUPING is, per spec, explicitly allowed anywhere you could have an
aggregate call, whether the group by clause is plain or not.

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: TABLESAMPLE patch is really in pretty sad shape
Next
From: Jeevan Chalke
Date:
Subject: Re: GSets: Fix bug involving GROUPING and HAVING together