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

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

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);