~ubuntu-branches/ubuntu/natty/postgresql-8.4/natty-security

« back to all changes in this revision

Viewing changes to src/backend/optimizer/plan/planagg.c

  • Committer: Bazaar Package Importer
  • Author(s): Martin Pitt
  • Date: 2009-07-11 16:59:35 UTC
  • mfrom: (5.1.1 karmic)
  • Revision ID: james.westby@ubuntu.com-20090711165935-jfwin6gfrxf0gfsi
Tags: 8.4.0-2
* debian/libpq-dev.install: Ship catalog/genbki.h. (Closes: #536139)
* debian/rules: Drop --enable-cassert for final release.

Show diffs side-by-side

added added

removed removed

Lines of Context:
8
8
 *
9
9
 *
10
10
 * IDENTIFICATION
11
 
 *        $PostgreSQL: pgsql/src/backend/optimizer/plan/planagg.c,v 1.45 2009/01/01 17:23:44 momjian Exp $
 
11
 *        $PostgreSQL: pgsql/src/backend/optimizer/plan/planagg.c,v 1.46 2009/06/11 14:48:59 momjian Exp $
12
12
 *
13
13
 *-------------------------------------------------------------------------
14
14
 */
96
96
         * Reject unoptimizable cases.
97
97
         *
98
98
         * We don't handle GROUP BY or windowing, because our current
99
 
         * implementations of grouping require looking at all the rows anyway,
100
 
         * and so there's not much point in optimizing MIN/MAX.
 
99
         * implementations of grouping require looking at all the rows anyway, and
 
100
         * so there's not much point in optimizing MIN/MAX.
101
101
         */
102
102
        if (parse->groupClause || parse->hasWindowFuncs)
103
103
                return NULL;
189
189
                                                                                         &aggs_list);
190
190
 
191
191
        /*
192
 
         * We have to replace Aggrefs with Params in equivalence classes too,
193
 
         * else ORDER BY or DISTINCT on an optimized aggregate will fail.
 
192
         * We have to replace Aggrefs with Params in equivalence classes too, else
 
193
         * ORDER BY or DISTINCT on an optimized aggregate will fail.
194
194
         *
195
 
         * Note: at some point it might become necessary to mutate other
196
 
         * data structures too, such as the query's sortClause or distinctClause.
197
 
         * Right now, those won't be examined after this point.
 
195
         * Note: at some point it might become necessary to mutate other data
 
196
         * structures too, such as the query's sortClause or distinctClause. Right
 
197
         * now, those won't be examined after this point.
198
198
         */
199
199
        mutate_eclass_expressions(root,
200
200
                                                          replace_aggs_with_params_mutator,