database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-16 06:01:02 +03:00
Code Activity

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

Browse Source 
Whatever we do about that, this isn't the path to the solution.
This commit is contained in:
Tom Lane
2008-03-29 00:15:37 +00:00
parent 707867e9fd
commit 92c3a80043
1 changed files with 1 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
src/backend/optimizer/plan/planner.c
View File

@ -8,7 +8,7 @@
* *
* *
* IDENTIFICATION * 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. * right tlist, and it has no sort order.
*/ */
current_pathkeys = NIL; 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 else
{ {