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

tglsfdc · tglsfdc · commit 92c3a8004308 · 2008-03-29T00:15:37.000Z
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
@@ -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
 		{

Original file line number	Diff line number	Diff line change
`@@ -8,7 +8,7 @@`
`8`	`8`	`*`
`9`	`9`	`*`
`10`	`10`	`* IDENTIFICATION`
`11`		`- * $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.226.2.1 2008/03/27 19:06:23 tgl Exp $`
	`11`	`+ * $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.226.2.2 2008/03/29 00:15:37 tgl Exp $`
`12`	`12`	`*`
`13`	`13`	`*-------------------------------------------------------------------------`
`14`	`14`	`*/`
`@@ -943,17 +943,6 @@ grouping_planner(PlannerInfo *root, double tuple_fraction)`
`943`	`943`	`* right tlist, and it has no sort order.`
`944`	`944`	`*/`
`945`	`945`	`current_pathkeys = NIL;`
`946`		`- /*`
`947`		`- * In fact, since we don't optimize grouped aggregates, it`
`948`		`- * needs no sort order --- there must be exactly one output row,`
`949`		`- * and so any ORDER BY or DISTINCT attached to the query is`
`950`		`- * useless and can be dropped. Aside from saving useless cycles,`
`951`		`- * this protects us against problems with matching the hacked-up`
`952`		`- * tlist entries to sort clauses.`
`953`		`- */`
`954`		`- Assert(!parse->groupClause);`
`955`		`- parse->sortClause = NULL;`
`956`		`- parse->distinctClause = NULL;`
`957`	`946`	`}`
`958`	`947`	`else`
`959`	`948`	`{`