mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Revert my erroneous fix for Taiki Yamaguchi's DISTINCT MAX() bug.

Browse Source 
Whatever we do about that, this isn't the path to the solution.
This commit is contained in:
Tom Lane 2008-03-29 00:15:28 +00:00
parent 2b350bc585
commit 6fc9d4272c
1 changed files with 1 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
src/backend/optimizer/plan/planner.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.229 2008/03/28 02:00:11 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.230 2008/03/29 00:15:28 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -835,21 +835,6 @@ grouping_planner(PlannerInfo *root, double tuple_fraction)
MemSet(&agg_counts, 0, sizeof(AggClauseCounts));
/*
* If the query involves ungrouped aggregation, then it can produce
* at most one row, so we can ignore any ORDER BY or DISTINCT
* request. This isn't all that exciting as an optimization, but it
* prevents a corner case when optimize_minmax_aggregates succeeds:
* if ORDER BY or DISTINCT were present we'd try, and fail, to match
* the EquivalenceClasses we're about to build with the modified
* targetlist entries it will create.
*/
if (parse->hasAggs && parse->groupClause == NIL)
{
parse->sortClause = NIL;
parse->distinctClause = NIL;
}
/* Preprocess targetlist */
tlist = preprocess_targetlist(root, tlist);