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

Whatever we do about that, this isn't the path to the solution.

diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 6d6078c138065f03c6d2f9d4033aeb0bd1b520ea..8f80a228c625753fcf26fd622119c0ceadd87df6 100644 (file)
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *   $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.226.2.1 2008/03/27 19:06:23 tgl Exp $
+ *   $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.226.2.2 2008/03/29 00:15:37 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -943,17 +943,6 @@ grouping_planner(PlannerInfo *root, double tuple_fraction)
             * right tlist, and it has no sort order.
             */
            current_pathkeys = NIL;
-           /*
-            * In fact, since we don't optimize grouped aggregates, it
-            * needs no sort order --- there must be exactly one output row,
-            * and so any ORDER BY or DISTINCT attached to the query is
-            * useless and can be dropped.  Aside from saving useless cycles,
-            * this protects us against problems with matching the hacked-up
-            * tlist entries to sort clauses.
-            */
-           Assert(!parse->groupClause);
-           parse->sortClause = NULL;
-           parse->distinctClause = NULL;
        }
        else
        {