Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> On 04/29/15 05:55, Tom Lane wrote:
>> pull_varnos is not, and should not be, applied to a RestrictInfo; for one
>> thing, it'd be redundant with work that was already done when creating the
>> RestrictInfo (cf make_restrictinfo_internal). You've not shown the
>> context of your problem very fully, but in general most code in the planner
>> should be well aware of whether it is working with a RestrictInfo (or list
>> of same) or a bare expression. I don't believe that it's a very good idea
>> to obscure that distinction.
> OK, let me explain the context a bit more. When working on the
> multivariate statistics patch, I need to choose which stats to use for
> estimating the clauses. I do that in clauselist_selectivity(), although
> there might be other places where to do that.
Hm, well, clauselist_selectivity and clause_selectivity already contain
extensive special-casing for RestrictInfos, so I'm not sure that I see why
you're having difficulty working within that structure for this change.
But there are basic reasons why expression_tree_walker should not try to
deal with RestrictInfos; the most obvious one being that it's not clear
whether it should descend into both the basic and OR-clause subtrees.
Also, if a node has expression_tree_walker support then it should
logically have expression_tree_mutator support as well, but that's
got multiple issues. RestrictInfos are not supposed to be copied
once created; and the mutator couldn't detect whether their derived
fields are still valid.
regards, tom lane