| blob | 69aa471319214d371bcc2bae3268d43ab5e3dcca |
1 /*-------------------------------------------------------------------------
2 *
3 * nodeFuncs.c
4 * Various general-purpose manipulations of Node trees
5 *
6 * Portions Copyright (c) 1996-2009, PostgreSQL Global Development Group
7 * Portions Copyright (c) 1994, Regents of the University of California
8 *
9 *
10 * IDENTIFICATION
11 * $PostgreSQL$
12 *
13 *-------------------------------------------------------------------------
14 */
29 /*
30 * exprType -
31 * returns the Oid of the type of the expression. (Used for typechecking.)
32 */
33 Oid
35 {
36 Oid type;
42 {
59 {
62 /* slice and/or store operations yield the array type */
65 else
67 }
85 {
90 {
91 /* get the type of the subselect's first target column */
102 {
109 }
110 }
111 else
112 {
113 /* for all other sublink types, result is boolean */
115 }
116 }
119 {
120 /*
121 * Although the parser does not ever deal with already-planned
122 * expression trees, we support SubPlan nodes in this routine
123 * for the convenience of ruleutils.c.
124 */
129 {
130 /* get the type of the subselect's first target column */
133 {
140 }
141 }
142 else
143 {
144 /* for all other subplan types, result is boolean */
146 }
147 }
150 {
151 /* As above, supported for the convenience of ruleutils.c */
154 /* subplans should all return the same thing */
156 }
202 else
233 }
235 }
237 /*
238 * exprTypmod -
239 * returns the type-specific attrmod of the expression, if it can be
240 * determined. In most cases, it can't and we return -1.
241 */
242 int32
244 {
249 {
257 /* typmod is the same for array or element */
260 {
261 int32 coercedTypmod;
263 /* Be smart about length-coercion functions... */
266 }
269 {
274 {
275 /* get the typmod of the subselect's first target column */
285 /* note we don't need to care if it's an array */
286 }
287 }
296 {
297 /*
298 * If all the alternatives agree on type/typmod, return that
299 * typmod, else use -1
300 */
303 int32 typmod;
314 {
322 }
324 }
329 {
330 /*
331 * If all the elements agree on type/typmod, return that
332 * typmod, else use -1
333 */
335 Oid commontype;
336 int32 typmod;
346 else
349 {
356 }
358 }
361 {
362 /*
363 * If all the alternatives agree on type/typmod, return that
364 * typmod, else use -1
365 */
368 int32 typmod;
377 {
384 }
386 }
389 {
390 /*
391 * If all the alternatives agree on type/typmod, return that
392 * typmod, else use -1
393 */
396 int32 typmod;
405 {
412 }
414 }
417 {
421 }
433 }
435 }
437 /*
438 * exprIsLengthCoercion
439 * Detect whether an expression tree is an application of a datatype's
440 * typmod-coercion function. Optionally extract the result's typmod.
441 *
442 * If coercedTypmod is not NULL, the typmod is stored there if the expression
443 * is a length-coercion function, else -1 is stored there.
444 *
445 * Note that a combined type-and-length coercion will be treated as a
446 * length coercion by this routine.
447 */
448 bool
450 {
454 /*
455 * Scalar-type length coercions are FuncExprs, array-type length coercions
456 * are ArrayCoerceExprs
457 */
459 {
464 /*
465 * If it didn't come from a coercion context, reject.
466 */
471 /*
472 * If it's not a two-argument or three-argument function with the
473 * second argument being an int4 constant, it can't have been created
474 * from a length coercion (it must be a type coercion, instead).
475 */
486 /*
487 * OK, it is indeed a length-coercion function.
488 */
493 }
496 {
499 /* It's not a length coercion unless there's a nondefault typmod */
503 /*
504 * OK, it is indeed a length-coercion expression.
505 */
510 }
513 }
515 /*
516 * expression_returns_set
517 * Test whether an expression returns a set result.
518 *
519 * Because we use expression_tree_walker(), this can also be applied to
520 * whole targetlists; it'll produce TRUE if any one of the tlist items
521 * returns a set.
522 */
523 bool
525 {
527 }
529 static bool
531 {
535 {
540 /* else fall through to check args */
541 }
543 {
548 /* else fall through to check args */
549 }
551 /* Avoid recursion for some cases that can't return a set */
584 context);
585 }
588 /*
589 * exprLocation -
590 * returns the parse location of an expression tree, for error reports
591 *
592 * -1 is returned if the location can't be determined.
593 *
594 * For expressions larger than a single token, the intent here is to
595 * return the location of the expression's leftmost token, not necessarily
596 * the topmost Node's location field. For example, an OpExpr's location
597 * field will point at the operator name, but if it is not a prefix operator
598 * then we should return the location of the left-hand operand instead.
599 * The reason is that we want to reference the entire expression not just
600 * that operator, and pointing to its start seems to be the most natural way.
601 *
602 * The location is not perfect --- for example, since the grammar doesn't
603 * explicitly represent parentheses in the parsetree, given something that
604 * had been written "(a + b) * c" we are going to point at "a" not "(".
605 * But it should be plenty good enough for error reporting purposes.
606 *
607 * You might think that this code is overly general, for instance why check
608 * the operands of a FuncExpr node, when the function name can be expected
609 * to be to the left of them? There are a couple of reasons. The grammar
610 * sometimes builds expressions that aren't quite what the user wrote;
611 * for instance x IS NOT BETWEEN ... becomes a NOT-expression whose keyword
612 * pointer is to the right of its leftmost argument. Also, nodes that were
613 * inserted implicitly by parse analysis (such as FuncExprs for implicit
614 * coercions) will have location -1, and so we can have odd combinations of
615 * known and unknown locations in a tree.
616 */
617 int
619 {
625 {
639 /* function name should always be the first thing */
643 /* function name should always be the first thing */
647 /* just use array argument's location */
651 {
654 /* consider both function name and leftmost arg */
657 }
662 {
665 /* consider both operator name and leftmost arg */
668 }
671 {
674 /* consider both operator name and leftmost arg */
677 }
680 {
683 /*
684 * Same as above, to handle either NOT or AND/OR. We can't
685 * special-case NOT because of the way that it's used for
686 * things like IS NOT BETWEEN.
687 */
690 }
693 {
696 /* check the testexpr, if any, and the operator/keyword */
699 }
702 /* just use argument's location */
706 /* just use argument's location */
710 {
713 /* Much as above */
716 }
719 {
722 /* Much as above */
725 }
728 {
731 /* Much as above */
734 }
737 {
740 /* Much as above */
743 }
746 /* CASE keyword should always be the first thing */
750 /* WHEN keyword should always be the first thing */
754 /* the location points at ARRAY or [, which must be leftmost */
758 /* the location points at ROW or (, which must be leftmost */
762 /* just use leftmost argument's location */
766 /* COALESCE keyword should always be the first thing */
770 /* GREATEST/LEAST keyword should always be the first thing */
774 {
777 /* consider both function name and leftmost arg */
780 }
783 /* just use argument's location */
787 /* just use argument's location */
791 {
794 /* Much as above */
797 }
806 /* just use argument's location */
810 /* use the contained RangeVar's location --- close enough */
814 {
815 /* report location of first list member that has a location */
820 {
824 }
825 }
828 {
831 /* use leftmost of operator or left operand (if any) */
832 /* we assume right operand can't be to left of operator */
835 }
847 {
850 /* consider both function name and leftmost arg */
853 }
856 /* the location points at ARRAY or [, which must be leftmost */
860 /* we need not examine the contained expression (if any) */
864 {
867 /*
868 * This could represent CAST(), ::, or TypeName 'literal',
869 * so any of the components might be leftmost.
870 */
874 }
877 /* just use argument's location (ignore operator, if any) */
887 /* XMLSERIALIZE keyword should always be the first thing */
897 /* just use argument's location */
901 /* for any other node type it's just unknown... */
904 }
906 }
908 /*
909 * leftmostLoc - support for exprLocation
910 *
911 * Take the minimum of two parse location values, but ignore unknowns
912 */
913 static int
915 {
920 else
922 }
925 /*
926 * Standard expression-tree walking support
927 *
928 * We used to have near-duplicate code in many different routines that
929 * understood how to recurse through an expression node tree. That was
930 * a pain to maintain, and we frequently had bugs due to some particular
931 * routine neglecting to support a particular node type. In most cases,
932 * these routines only actually care about certain node types, and don't
933 * care about other types except insofar as they have to recurse through
934 * non-primitive node types. Therefore, we now provide generic tree-walking
935 * logic to consolidate the redundant "boilerplate" code. There are
936 * two versions: expression_tree_walker() and expression_tree_mutator().
937 */
939 /*
940 * expression_tree_walker() is designed to support routines that traverse
941 * a tree in a read-only fashion (although it will also work for routines
942 * that modify nodes in-place but never add/delete/replace nodes).
943 * A walker routine should look like this:
944 *
945 * bool my_walker (Node *node, my_struct *context)
946 * {
947 * if (node == NULL)
948 * return false;
949 * // check for nodes that special work is required for, eg:
950 * if (IsA(node, Var))
951 * {
952 * ... do special actions for Var nodes
953 * }
954 * else if (IsA(node, ...))
955 * {
956 * ... do special actions for other node types
957 * }
958 * // for any node type not specially processed, do:
959 * return expression_tree_walker(node, my_walker, (void *) context);
960 * }
961 *
962 * The "context" argument points to a struct that holds whatever context
963 * information the walker routine needs --- it can be used to return data
964 * gathered by the walker, too. This argument is not touched by
965 * expression_tree_walker, but it is passed down to recursive sub-invocations
966 * of my_walker. The tree walk is started from a setup routine that
967 * fills in the appropriate context struct, calls my_walker with the top-level
968 * node of the tree, and then examines the results.
969 *
970 * The walker routine should return "false" to continue the tree walk, or
971 * "true" to abort the walk and immediately return "true" to the top-level
972 * caller. This can be used to short-circuit the traversal if the walker
973 * has found what it came for. "false" is returned to the top-level caller
974 * iff no invocation of the walker returned "true".
975 *
976 * The node types handled by expression_tree_walker include all those
977 * normally found in target lists and qualifier clauses during the planning
978 * stage. In particular, it handles List nodes since a cnf-ified qual clause
979 * will have List structure at the top level, and it handles TargetEntry nodes
980 * so that a scan of a target list can be handled without additional code.
981 * Also, RangeTblRef, FromExpr, JoinExpr, and SetOperationStmt nodes are
982 * handled, so that query jointrees and setOperation trees can be processed
983 * without additional code.
984 *
985 * expression_tree_walker will handle SubLink nodes by recursing normally
986 * into the "testexpr" subtree (which is an expression belonging to the outer
987 * plan). It will also call the walker on the sub-Query node; however, when
988 * expression_tree_walker itself is called on a Query node, it does nothing
989 * and returns "false". The net effect is that unless the walker does
990 * something special at a Query node, sub-selects will not be visited during
991 * an expression tree walk. This is exactly the behavior wanted in many cases
992 * --- and for those walkers that do want to recurse into sub-selects, special
993 * behavior is typically needed anyway at the entry to a sub-select (such as
994 * incrementing a depth counter). A walker that wants to examine sub-selects
995 * should include code along the lines of:
996 *
997 * if (IsA(node, Query))
998 * {
999 * adjust context for subquery;
1000 * result = query_tree_walker((Query *) node, my_walker, context,
1001 * 0); // adjust flags as needed
1002 * restore context if needed;
1003 * return result;
1004 * }
1005 *
1006 * query_tree_walker is a convenience routine (see below) that calls the
1007 * walker on all the expression subtrees of the given Query node.
1008 *
1009 * expression_tree_walker will handle SubPlan nodes by recursing normally
1010 * into the "testexpr" and the "args" list (which are expressions belonging to
1011 * the outer plan). It will not touch the completed subplan, however. Since
1012 * there is no link to the original Query, it is not possible to recurse into
1013 * subselects of an already-planned expression tree. This is OK for current
1014 * uses, but may need to be revisited in future.
1015 */
1017 bool
1021 {
1024 /*
1025 * The walker has already visited the current node, and so we need only
1026 * recurse into any sub-nodes it has.
1027 *
1028 * We assume that the walker is not interested in List nodes per se, so
1029 * when we expect a List we just recurse directly to self without
1030 * bothering to call the walker.
1031 */
1035 /* Guard against stack overflow due to overly complex expressions */
1039 {
1048 /* primitive node types with no expression subnodes */
1051 {
1054 /* recurse directly on List */
1058 }
1061 {
1064 /* recurse directly on List */
1068 }
1071 {
1074 /* recurse directly for upper/lower array index lists */
1081 /* walker must see the refexpr and refassgnexpr, however */
1086 }
1089 {
1095 }
1098 {
1104 }
1107 {
1113 }
1116 {
1122 }
1125 {
1131 }
1134 {
1140 /*
1141 * Also invoke the walker on the sublink's Query node, so it
1142 * can recurse into the sub-query if it wants to.
1143 */
1145 }
1148 {
1151 /* recurse into the testexpr, but not into the Plan */
1154 /* also examine args list */
1158 }
1165 {
1172 }
1183 {
1188 /* we assume walker doesn't care about CaseWhens, either */
1190 {
1198 }
1201 }
1206 /* Assume colnames isn't interesting */
1209 {
1216 }
1223 {
1228 /* we assume walker doesn't care about arg_names */
1231 }
1244 /* Do nothing with a sub-Query, per discussion above */
1247 {
1254 }
1257 {
1260 /*
1261 * Invoke the walker on the CTE's Query node, so it
1262 * can recurse into the sub-query if it wants to.
1263 */
1265 }
1269 {
1272 }
1275 {
1282 }
1285 {
1295 /*
1296 * alias clause, using list are deemed uninteresting.
1297 */
1298 }
1301 {
1309 /* groupClauses are deemed uninteresting */
1310 }
1315 {
1321 }
1329 }
1331 }
1333 /*
1334 * query_tree_walker --- initiate a walk of a Query's expressions
1335 *
1336 * This routine exists just to reduce the number of places that need to know
1337 * where all the expression subtrees of a Query are. Note it can be used
1338 * for starting a walk at top level of a Query regardless of whether the
1339 * walker intends to descend into subqueries. It is also useful for
1340 * descending into subqueries within a walker.
1341 *
1342 * Some callers want to suppress visitation of certain items in the sub-Query,
1343 * typically because they need to process them specially, or don't actually
1344 * want to recurse into subqueries. This is supported by the flags argument,
1345 * which is the bitwise OR of flag values to suppress visitation of
1346 * indicated items. (More flag bits may be added as needed.)
1347 */
1348 bool
1353 {
1371 {
1374 }
1378 }
1380 /*
1381 * range_table_walker is just the part of query_tree_walker that scans
1382 * a query's rangetable. This is split out since it can be useful on
1383 * its own.
1384 */
1385 bool
1390 {
1394 {
1397 /* For historical reasons, visiting RTEs is not the default */
1403 {
1407 /* nothing to do */
1427 }
1428 }
1430 }
1433 /*
1434 * expression_tree_mutator() is designed to support routines that make a
1435 * modified copy of an expression tree, with some nodes being added,
1436 * removed, or replaced by new subtrees. The original tree is (normally)
1437 * not changed. Each recursion level is responsible for returning a copy of
1438 * (or appropriately modified substitute for) the subtree it is handed.
1439 * A mutator routine should look like this:
1440 *
1441 * Node * my_mutator (Node *node, my_struct *context)
1442 * {
1443 * if (node == NULL)
1444 * return NULL;
1445 * // check for nodes that special work is required for, eg:
1446 * if (IsA(node, Var))
1447 * {
1448 * ... create and return modified copy of Var node
1449 * }
1450 * else if (IsA(node, ...))
1451 * {
1452 * ... do special transformations of other node types
1453 * }
1454 * // for any node type not specially processed, do:
1455 * return expression_tree_mutator(node, my_mutator, (void *) context);
1456 * }
1457 *
1458 * The "context" argument points to a struct that holds whatever context
1459 * information the mutator routine needs --- it can be used to return extra
1460 * data gathered by the mutator, too. This argument is not touched by
1461 * expression_tree_mutator, but it is passed down to recursive sub-invocations
1462 * of my_mutator. The tree walk is started from a setup routine that
1463 * fills in the appropriate context struct, calls my_mutator with the
1464 * top-level node of the tree, and does any required post-processing.
1465 *
1466 * Each level of recursion must return an appropriately modified Node.
1467 * If expression_tree_mutator() is called, it will make an exact copy
1468 * of the given Node, but invoke my_mutator() to copy the sub-node(s)
1469 * of that Node. In this way, my_mutator() has full control over the
1470 * copying process but need not directly deal with expression trees
1471 * that it has no interest in.
1472 *
1473 * Just as for expression_tree_walker, the node types handled by
1474 * expression_tree_mutator include all those normally found in target lists
1475 * and qualifier clauses during the planning stage.
1476 *
1477 * expression_tree_mutator will handle SubLink nodes by recursing normally
1478 * into the "testexpr" subtree (which is an expression belonging to the outer
1479 * plan). It will also call the mutator on the sub-Query node; however, when
1480 * expression_tree_mutator itself is called on a Query node, it does nothing
1481 * and returns the unmodified Query node. The net effect is that unless the
1482 * mutator does something special at a Query node, sub-selects will not be
1483 * visited or modified; the original sub-select will be linked to by the new
1484 * SubLink node. Mutators that want to descend into sub-selects will usually
1485 * do so by recognizing Query nodes and calling query_tree_mutator (below).
1486 *
1487 * expression_tree_mutator will handle a SubPlan node by recursing into the
1488 * "testexpr" and the "args" list (which belong to the outer plan), but it
1489 * will simply copy the link to the inner plan, since that's typically what
1490 * expression tree mutators want. A mutator that wants to modify the subplan
1491 * can force appropriate behavior by recognizing SubPlan expression nodes
1492 * and doing the right thing.
1493 */
1495 Node *
1499 {
1500 /*
1501 * The mutator has already decided not to modify the current node, but we
1502 * must call the mutator for any sub-nodes.
1503 */
1505 #define FLATCOPY(newnode, node, nodetype) \
1506 ( (newnode) = (nodetype *) palloc(sizeof(nodetype)), \
1507 memcpy((newnode), (node), sizeof(nodetype)) )
1509 #define CHECKFLATCOPY(newnode, node, nodetype) \
1510 ( AssertMacro(IsA((node), nodetype)), \
1511 (newnode) = (nodetype *) palloc(sizeof(nodetype)), \
1512 memcpy((newnode), (node), sizeof(nodetype)) )
1514 #define MUTATE(newfield, oldfield, fieldtype) \
1515 ( (newfield) = (fieldtype) mutator((Node *) (oldfield), context) )
1520 /* Guard against stack overflow due to overly complex expressions */
1524 {
1525 /*
1526 * Primitive node types with no expression subnodes. Var and
1527 * Const are frequent enough to deserve special cases, the others
1528 * we just use copyObject for.
1529 */
1531 {
1537 }
1540 {
1545 /* XXX we don't bother with datumCopy; should we? */
1547 }
1557 {
1564 }
1567 {
1574 }
1577 {
1583 List *);
1585 List *);
1587 Expr *);
1589 Expr *);
1591 }
1594 {
1601 }
1604 {
1611 }
1614 {
1621 }
1624 {
1631 }
1634 {
1641 }
1644 {
1651 /*
1652 * Also invoke the mutator on the sublink's Query node, so it
1653 * can recurse into the sub-query if it wants to.
1654 */
1657 }
1660 {
1665 /* transform testexpr */
1667 /* transform args list (params to be passed to subplan) */
1669 /* but not the sub-Plan itself, which is referenced as-is */
1671 }
1674 {
1681 }
1684 {
1691 }
1694 {
1703 }
1706 {
1713 }
1716 {
1723 }
1726 {
1733 }
1736 {
1743 }
1746 {
1755 }
1758 {
1766 }
1769 {
1776 }
1779 {
1785 /* Assume colnames needn't be duplicated */
1787 }
1790 {
1798 }
1801 {
1808 }
1811 {
1818 }
1821 {
1827 /* assume mutator does not care about arg_names */
1830 }
1833 {
1840 }
1843 {
1850 }
1853 {
1860 }
1863 {
1870 }
1873 {
1880 }
1883 /* Do nothing with a sub-Query, per discussion above */
1886 {
1894 }
1897 {
1903 /*
1904 * Also invoke the mutator on the CTE's Query node, so it
1905 * can recurse into the sub-query if it wants to.
1906 */
1909 }
1912 {
1913 /*
1914 * We assume the mutator isn't interested in the list nodes
1915 * per se, so just invoke it on each list element. NOTE: this
1916 * would fail badly on a list with integer elements!
1917 */
1923 {
1926 context));
1927 }
1929 }
1932 {
1940 }
1943 {
1951 /* We do not mutate alias or using by default */
1953 }
1956 {
1963 /* We do not mutate groupClauses by default */
1965 }
1968 {
1974 /* Assume we need not copy the relids bitmapset */
1976 }
1979 {
1986 }
1989 {
1995 /* Assume we need not copy the relids bitmapsets */
1997 }
2003 }
2004 /* can't get here, but keep compiler happy */
2006 }
2009 /*
2010 * query_tree_mutator --- initiate modification of a Query's expressions
2011 *
2012 * This routine exists just to reduce the number of places that need to know
2013 * where all the expression subtrees of a Query are. Note it can be used
2014 * for starting a walk at top level of a Query regardless of whether the
2015 * mutator intends to descend into subqueries. It is also useful for
2016 * descending into subqueries within a mutator.
2017 *
2018 * Some callers want to suppress mutating of certain items in the Query,
2019 * typically because they need to process them specially, or don't actually
2020 * want to recurse into subqueries. This is supported by the flags argument,
2021 * which is the bitwise OR of flag values to suppress mutating of
2022 * indicated items. (More flag bits may be added as needed.)
2023 *
2024 * Normally the Query node itself is copied, but some callers want it to be
2025 * modified in-place; they must pass QTW_DONT_COPY_QUERY in flags. All
2026 * modified substructure is safely copied in any case.
2027 */
2028 Query *
2033 {
2037 {
2042 }
2058 }
2060 /*
2061 * range_table_mutator is just the part of query_tree_mutator that processes
2062 * a query's rangetable. This is split out since it can be useful on
2063 * its own.
2064 */
2065 List *
2070 {
2075 {
2081 {
2085 /* we don't bother to copy eref, aliases, etc; OK? */
2089 {
2092 }
2093 else
2094 {
2095 /* else, copy RT subqueries as-is */
2097 }
2102 else
2103 {
2104 /* else, copy join aliases as-is */
2106 }
2114 }
2116 }
2118 }
2120 /*
2121 * query_or_expression_tree_walker --- hybrid form
2122 *
2123 * This routine will invoke query_tree_walker if called on a Query node,
2124 * else will invoke the walker directly. This is a useful way of starting
2125 * the recursion when the walker's normal change of state is not appropriate
2126 * for the outermost Query node.
2127 */
2128 bool
2133 {
2136 walker,
2137 context,
2138 flags);
2139 else
2141 }
2143 /*
2144 * query_or_expression_tree_mutator --- hybrid form
2145 *
2146 * This routine will invoke query_tree_mutator if called on a Query node,
2147 * else will invoke the mutator directly. This is a useful way of starting
2148 * the recursion when the mutator's normal change of state is not appropriate
2149 * for the outermost Query node.
2150 */
2151 Node *
2156 {
2159 mutator,
2160 context,
2161 flags);
2162 else
2164 }
2167 /*
2168 * raw_expression_tree_walker --- walk raw parse trees
2169 *
2170 * This has exactly the same API as expression_tree_walker, but instead of
2171 * walking post-analysis parse trees, it knows how to walk the node types
2172 * found in raw grammar output. (There is not currently any need for a
2173 * combined walker, so we keep them separate in the name of efficiency.)
2174 * Unlike expression_tree_walker, there is no special rule about query
2175 * boundaries: we descend to everything that's possibly interesting.
2176 *
2177 * Currently, the node type coverage extends to SelectStmt and everything
2178 * that could appear under it, but not other statement types.
2179 */
2180 bool
2182 {
2185 /*
2186 * The walker has already visited the current node, and so we need only
2187 * recurse into any sub-nodes it has.
2188 */
2192 /* Guard against stack overflow due to overly complex expressions */
2196 {
2207 /* primitive node types with no subnodes */
2210 /* we assume the colnames list isn't interesting */
2215 {
2220 /* we assume the operName is not interesting */
2223 }
2226 {
2231 /* we assume walker doesn't care about CaseWhens, either */
2233 {
2241 }
2244 }
2247 /* Assume colnames isn't interesting */
2254 {
2259 /* we assume walker doesn't care about arg_names */
2262 }
2269 {
2280 /* using list is deemed uninteresting */
2281 }
2284 {
2289 /* colNames, options are deemed uninteresting */
2290 }
2294 {
2297 }
2300 {
2335 }
2338 {
2345 /* operator name is deemed uninteresting */
2346 }
2349 /* we assume the fields contain nothing interesting */
2352 {
2359 /* function name is deemed uninteresting */
2360 }
2363 {
2370 }
2373 {
2380 }
2385 {
2392 }
2395 {
2402 }
2407 {
2414 }
2417 {
2424 }
2427 {
2434 }
2437 {
2444 /* type name itself is deemed uninteresting */
2445 }
2448 {
2455 /* for now, constraints are ignored */
2456 }
2461 {
2468 }
2478 }
2480 }