From 92c3a800430889f1d461295f3e1158a4255c6d13 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sat, 29 Mar 2008 00:15:37 +0000 Subject: [PATCH] Revert my erroneous fix for Taiki Yamaguchi's DISTINCT MAX() bug. Whatever we do about that, this isn't the path to the solution. --- src/backend/optimizer/plan/planner.c | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c index 6d6078c138..8f80a228c6 100644 --- 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 { -- 2.50.0