Anybody using mutate_eclass_expressions() from add-on code?

I looked into the problem reported in bug #7703, namely that queries
such as
select distinct min(x) from tab;
fail if "tab" is an inheritance tree and an index-optimized plan
using MergeAppend is possible. What's happening is that
(1) the use of DISTINCT causes us to create an EquivalenceClass
containing min(x), which is needed since we may have to reason about
sorting on that expression;
(2) expansion of the inheritance tree causes us to add child
EquivalenceClass members representing min() applied to each of tab's
child tables;
(3) when planagg.c tries to replace min(x) with a Param, the
mutate_eclass_expressions(..., replace_aggs_with_params_mutator, ...)
call spits up because it doesn't know what to do with the child-table
min() expressions.

I thought about fixing this by just changing
replace_aggs_with_params_mutator to not complain about unmatched
aggregate expressions, but that seems awfully likely to obscure future
bugs. What seems like a better fix is to change the processing so that
child EquivalenceClass members aren't processed when doing the Param
replacement --- this should be OK since we won't need them after this
point. However, that requires changing the behavior of
mutate_eclass_expressions(). In the attached proposed patch I added a
new bool parameter to control whether child expressions are mutated.

This needs to be back-patched to 9.1, but I'm slightly worried about
whether changing the function's API in back branches would break any
add-on code. It seems fairly unlikely that anything outside the core
planner is calling this function, but I thought I'd better ask.

Comments?

regards, tom lane