Revert my erroneous fix for Taiki Yamaguchi's DISTINCT MAX() bug.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 29 Mar 2008 00:15:37 +0000 (00:15 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 29 Mar 2008 00:15:37 +0000 (00:15 +0000)
Whatever we do about that, this isn't the path to the solution.

src/backend/optimizer/plan/planner.c

index f37399a37a932eaca266ad64a56bf020ced2a079..2c22840fbdc74ade2f2dfd60890e841cce21e207 100644 (file)
@@ -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
                {