diff options
| author | Tom Lane | 2019-01-29 20:26:44 +0000 |
|---|---|---|
| committer | Tom Lane | 2019-01-29 20:26:44 +0000 |
| commit | a1b8c41e990ec0f083e9b684700a07640d5a356a (patch) | |
| tree | daa26b95223c1e2a09507973853aa77b91df7644 /src/backend/optimizer/util/orclauses.c | |
| parent | e77cfa54d700557ea700d47454c9e570f20f1841 (diff) | |
Make some small planner API cleanups.
Move a few very simple node-creation and node-type-testing functions
from the planner's clauses.c to nodes/makefuncs and nodes/nodeFuncs.
There's nothing planner-specific about them, as evidenced by the
number of other places that were using them.
While at it, rename and_clause() etc to is_andclause() etc, to clarify
that they are node-type-testing functions not node-creation functions.
And use "static inline" implementations for the shortest ones.
Also, modify flatten_join_alias_vars() and some subsidiary functions
to take a Query not a PlannerInfo to define the join structure that
Vars should be translated according to. They were only using the
"parse" field of the PlannerInfo anyway, so this just requires removing
one level of indirection. The advantage is that now parse_agg.c can
use flatten_join_alias_vars() without the horrid kluge of creating an
incomplete PlannerInfo, which will allow that file to be decoupled from
relation.h in a subsequent patch.
Discussion: https://postgr.es/m/[email protected]
Diffstat (limited to 'src/backend/optimizer/util/orclauses.c')
| -rw-r--r-- | src/backend/optimizer/util/orclauses.c | 8 |
1 files changed, 5 insertions, 3 deletions
diff --git a/src/backend/optimizer/util/orclauses.c b/src/backend/optimizer/util/orclauses.c index 9420f1347ae..c62ba88d1b2 100644 --- a/src/backend/optimizer/util/orclauses.c +++ b/src/backend/optimizer/util/orclauses.c @@ -15,6 +15,8 @@ #include "postgres.h" +#include "nodes/makefuncs.h" +#include "nodes/nodeFuncs.h" #include "optimizer/clauses.h" #include "optimizer/cost.h" #include "optimizer/orclauses.h" @@ -173,7 +175,7 @@ extract_or_clause(RestrictInfo *or_rinfo, RelOptInfo *rel) * selectivity and other cached data is computed exactly the same way for * a restriction clause as for a join clause, which seems undesirable. */ - Assert(or_clause((Node *) or_rinfo->orclause)); + Assert(is_orclause(or_rinfo->orclause)); foreach(lc, ((BoolExpr *) or_rinfo->orclause)->args) { Node *orarg = (Node *) lfirst(lc); @@ -181,7 +183,7 @@ extract_or_clause(RestrictInfo *or_rinfo, RelOptInfo *rel) Node *subclause; /* OR arguments should be ANDs or sub-RestrictInfos */ - if (and_clause(orarg)) + if (is_andclause(orarg)) { List *andargs = ((BoolExpr *) orarg)->args; ListCell *lc2; @@ -231,7 +233,7 @@ extract_or_clause(RestrictInfo *or_rinfo, RelOptInfo *rel) * to preserve AND/OR flatness (ie, no OR directly underneath OR). */ subclause = (Node *) make_ands_explicit(subclauses); - if (or_clause(subclause)) + if (is_orclause(subclause)) clauselist = list_concat(clauselist, list_copy(((BoolExpr *) subclause)->args)); else |