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
                {