pgsql: Rethink the order of expression preprocessing:

Log Message:
-----------
Rethink the order of expression preprocessing: eval_const_expressions
really ought to run before canonicalize_qual, because it can now produce
forms that canonicalize_qual knows how to improve (eg, NOT clauses).
Also, because eval_const_expressions already knows about flattening
nested ANDs and ORs into N-argument form, the initial flatten_andors
pass in canonicalize_qual is now completely redundant and can be
removed. This doesn't save a whole lot of code, but the time and
palloc traffic eliminated is a useful gain on large expression trees.

Modified Files:
--------------
pgsql/src/backend/optimizer/path:
indxpath.c (r1.171 -> r1.172)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/indxpath.c.diff?r1=1.171&r2=1.172)
pgsql/src/backend/optimizer/plan:
planner.c (r1.180 -> r1.181)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planner.c.diff?r1=1.180&r2=1.181)
pgsql/src/backend/optimizer/prep:
prepqual.c (r1.48 -> r1.49)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/prep/prepqual.c.diff?r1=1.48&r2=1.49)
pgsql/src/backend/optimizer/util:
clauses.c (r1.189 -> r1.190)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/clauses.c.diff?r1=1.189&r2=1.190)
restrictinfo.c (r1.31 -> r1.32)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/restrictinfo.c.diff?r1=1.31&r2=1.32)
pgsql/src/backend/utils/cache:
relcache.c (r1.216 -> r1.217)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/relcache.c.diff?r1=1.216&r2=1.217)
pgsql/src/include/optimizer:
prep.h (r1.48 -> r1.49)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/optimizer/prep.h.diff?r1=1.48&r2=1.49)