Re: FIX : teach expression walker about RestrictInfo
От | Tom Lane |
---|---|
Тема | Re: FIX : teach expression walker about RestrictInfo |
Дата | |
Msg-id | 35395.1430324773@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: FIX : teach expression walker about RestrictInfo (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: FIX : teach expression walker about RestrictInfo
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: