| blob | 58cef1cfc95dfeee559deeba9693849b67715efd |
1 /*-------------------------------------------------------------------------
2 *
3 * parse_clause.c
4 * handle clauses in parser
5 *
6 * Portions Copyright (c) 1996-2008, PostgreSQL Global Development Group
7 * Portions Copyright (c) 1994, Regents of the University of California
8 *
9 *
10 * IDENTIFICATION
11 * $PostgreSQL$
12 *
13 *-------------------------------------------------------------------------
14 */
40 #define ORDER_CLAUSE 0
41 #define GROUP_CLAUSE 1
42 #define DISTINCT_ON_CLAUSE 2
55 Relids containedRels);
81 /*
82 * transformFromClause -
83 * Process the FROM clause and add items to the query's range table,
84 * joinlist, and namespaces.
85 *
86 * Note: we assume that pstate's p_rtable, p_joinlist, p_relnamespace, and
87 * p_varnamespace lists were initialized to NIL when the pstate was created.
88 * We will add onto any entries already present --- this is needed for rule
89 * processing, as well as for UPDATE and DELETE.
90 *
91 * The range table may grow still further when we transform the expressions
92 * in the query's quals and target list. (This is possible because in
93 * POSTQUEL, we allowed references to relations not specified in the
94 * from-clause. PostgreSQL keeps this extension to standard SQL.)
95 */
96 void
98 {
101 /*
102 * The grammar will have produced a list of RangeVars, RangeSubselects,
103 * RangeFunctions, and/or JoinExprs. Transform each one (possibly adding
104 * entries to the rtable), check for duplicate refnames, and then add it
105 * to the joinlist and namespaces.
106 */
108 {
113 Relids containedRels;
123 relnamespace);
126 }
127 }
129 /*
130 * setTargetTable
131 * Add the target relation of INSERT/UPDATE/DELETE to the range table,
132 * and make the special links to it in the ParseState.
133 *
134 * We also open the target relation and acquire a write lock on it.
135 * This must be done before processing the FROM list, in case the target
136 * is also mentioned as a source relation --- we want to be sure to grab
137 * the write lock before any read lock.
138 *
139 * If alsoSource is true, add the target to the query's joinlist and
140 * namespace. For INSERT, we don't want the target to be joined to;
141 * it's a destination of tuples, not a source. For UPDATE/DELETE,
142 * we do need to scan or join the target. (NOTE: we do not bother
143 * to check for namespace conflict; we assume that the namespace was
144 * initially empty in these cases.)
145 *
146 * Finally, we mark the relation as requiring the permissions specified
147 * by requiredPerms.
148 *
149 * Returns the rangetable index of the target relation.
150 */
151 int
154 {
158 /* Close old target; this could only happen for multi-action rules */
162 /*
163 * Open target rel and grab suitable lock (which we will hold till end of
164 * transaction).
165 *
166 * free_parsestate() will eventually do the corresponding heap_close(),
167 * but *not* release the lock.
168 */
170 RowExclusiveLock);
172 /*
173 * Now build an RTE.
174 */
179 /* assume new rte is at end */
183 /*
184 * Override addRangeTableEntry's default ACL_SELECT permissions check, and
185 * instead mark target table as requiring exactly the specified
186 * permissions.
187 *
188 * If we find an explicit reference to the rel later during parse
189 * analysis, we will add the ACL_SELECT bit back again; see
190 * scanRTEForColumn (for simple field references), ExpandColumnRefStar
191 * (for foo.*) and ExpandAllTables (for *).
192 */
195 /*
196 * If UPDATE/DELETE, add table to joinlist and namespaces.
197 */
202 }
204 /*
205 * Simplify InhOption (yes/no/default) into boolean yes/no.
206 *
207 * The reason we do things this way is that we don't want to examine the
208 * SQL_inheritance option flag until parse_analyze() is run. Otherwise,
209 * we'd do the wrong thing with query strings that intermix SET commands
210 * with queries.
211 */
212 bool
214 {
216 {
223 }
226 }
228 /*
229 * Given a relation-options list (of DefElems), return true iff the specified
230 * table/result set should be created with OIDs. This needs to be done after
231 * parsing the query string because the return value can depend upon the
232 * default_with_oids GUC var.
233 */
234 bool
236 {
239 /* Scan list to see if OIDS was included */
241 {
246 }
248 /* OIDS option was not specified, so use default. */
250 }
252 /*
253 * Extract all not-in-common columns from column lists of a source table
254 */
255 static void
259 {
268 {
274 {
278 {
281 }
282 }
285 {
288 }
289 }
293 }
295 /* transformJoinUsingClause()
296 * Build a complete ON clause from a partially-transformed USING list.
297 * We are given lists of nodes representing left and right match columns.
298 * Result is a transformed qualification expression.
299 */
302 {
307 /*
308 * We cheat a little bit here by building an untransformed operator tree
309 * whose leaves are the already-transformed Vars. This is OK because
310 * transformExpr() won't complain about already-transformed subnodes.
311 */
313 {
324 else
325 {
330 }
331 }
333 /*
334 * Since the references are already Vars, and are certainly from the input
335 * relations, we don't have to go through the same pushups that
336 * transformJoinOnClause() does. Just invoke transformExpr() to fix up
337 * the operators, and we're done.
338 */
344 }
346 /* transformJoinOnClause()
347 * Transform the qual conditions for JOIN/ON.
348 * Result is a transformed qualification expression.
349 */
355 Relids containedRels)
356 {
360 Relids clause_varnos;
363 /*
364 * This is a tad tricky, for two reasons. First, the namespace that the
365 * join expression should see is just the two subtrees of the JOIN plus
366 * any outer references from upper pstate levels. So, temporarily set
367 * this pstate's namespace accordingly. (We need not check for refname
368 * conflicts, because transformFromClauseItem() already did.) NOTE: this
369 * code is OK only because the ON clause can't legally alter the namespace
370 * by causing implicit relation refs to be added.
371 */
383 /*
384 * Second, we need to check that the ON condition doesn't refer to any
385 * rels outside the input subtrees of the JOIN. It could do that despite
386 * our hack on the namespace if it uses fully-qualified names. So, grovel
387 * through the transformed clause and make sure there are no bogus
388 * references. (Outer references are OK, and are ignored here.)
389 */
393 {
400 }
404 }
406 /*
407 * transformTableEntry --- transform a RangeVar (simple relation reference)
408 */
411 {
414 /*
415 * mark this entry to indicate it comes from the FROM clause. In SQL, the
416 * target list can only refer to range variables specified in the from
417 * clause but we follow the more powerful POSTQUEL semantics and
418 * automatically generate the range variable if not specified. However
419 * there are times we need to know whether the entries are legitimate.
420 */
425 }
427 /*
428 * transformCTEReference --- transform a RangeVar that references a common
429 * table expression (ie, a sub-SELECT defined in a WITH clause)
430 */
434 {
440 }
442 /*
443 * transformRangeSubselect --- transform a sub-SELECT appearing in FROM
444 */
447 {
451 /*
452 * We require user to supply an alias for a subselect, per SQL92. To relax
453 * this, we'd have to be prepared to gin up a unique alias for an
454 * unlabeled subselect. (This is just elog, not ereport, because the
455 * grammar should have enforced it already.)
456 */
460 /*
461 * Analyze and transform the subquery.
462 */
465 /*
466 * Check that we got something reasonable. Many of these conditions are
467 * impossible given restrictions of the grammar, but check 'em anyway.
468 */
480 /*
481 * The subquery cannot make use of any variables from FROM items created
482 * earlier in the current query. Per SQL92, the scope of a FROM item does
483 * not include other FROM items. Formerly we hacked the namespace so that
484 * the other variables weren't even visible, but it seems more useful to
485 * leave them visible and give a specific error message.
486 *
487 * XXX this will need further work to support SQL99's LATERAL() feature,
488 * wherein such references would indeed be legal.
489 *
490 * We can skip groveling through the subquery if there's not anything
491 * visible in the current query. Also note that outer references are OK.
492 */
494 {
501 }
503 /*
504 * OK, build an RTE for the subquery.
505 */
509 }
512 /*
513 * transformRangeFunction --- transform a function call appearing in FROM
514 */
517 {
522 /*
523 * Get function name for possible use as alias. We use the same
524 * transformation rules as for a SELECT output expression. For a FuncCall
525 * node, the result will be the function name, but it is possible for the
526 * grammar to hand back other node types.
527 */
530 /*
531 * Transform the raw expression.
532 */
535 /*
536 * The function parameters cannot make use of any variables from other
537 * FROM items. (Compare to transformRangeSubselect(); the coding is
538 * different though because we didn't parse as a sub-select with its own
539 * level of namespace.)
540 *
541 * XXX this will need further work to support SQL99's LATERAL() feature,
542 * wherein such references would indeed be legal.
543 */
545 {
552 }
554 /*
555 * Disallow aggregate functions in the expression. (No reason to postpone
556 * this check until parseCheckAggregates.)
557 */
559 {
566 }
568 /*
569 * OK, build an RTE for the function.
570 */
574 /*
575 * If a coldeflist was supplied, ensure it defines a legal set of names
576 * (no duplicates) and datatypes (no pseudo-types, for instance).
577 * addRangeTableEntryForFunction looked up the type names but didn't check
578 * them further than that.
579 */
581 {
582 TupleDesc tupdesc;
588 }
591 }
594 /*
595 * transformFromClauseItem -
596 * Transform a FROM-clause item, adding any required entries to the
597 * range table list being built in the ParseState, and return the
598 * transformed item ready to include in the joinlist and namespaces.
599 * This routine can recurse to handle SQL92 JOIN expressions.
600 *
601 * The function return value is the node to add to the jointree (a
602 * RangeTblRef or JoinExpr). Additional output parameters are:
603 *
604 * *top_rte: receives the RTE corresponding to the jointree item.
605 * (We could extract this from the function return node, but it saves cycles
606 * to pass it back separately.)
607 *
608 * *top_rti: receives the rangetable index of top_rte. (Ditto.)
609 *
610 * *relnamespace: receives a List of the RTEs exposed as relation names
611 * by this item.
612 *
613 * *containedRels: receives a bitmap set of the rangetable indexes
614 * of all the base and join relations represented in this jointree item.
615 * This is needed for checking JOIN/ON conditions in higher levels.
616 *
617 * We do not need to pass back an explicit varnamespace value, because
618 * in all cases the varnamespace contribution is exactly top_rte.
619 */
625 {
627 {
628 /* Plain relation reference, or perhaps a CTE reference */
634 /* if it is an unqualified name, it might be a CTE reference */
636 {
638 Index levelsup;
643 }
645 /* if not found as a CTE, must be a table reference */
649 /* assume new rte is at end */
659 }
661 {
662 /* sub-SELECT is like a plain relation */
668 /* assume new rte is at end */
678 }
680 {
681 /* function is like a plain relation */
687 /* assume new rte is at end */
697 }
699 {
700 /* A newfangled join expression */
706 Relids l_containedRels,
707 r_containedRels,
708 my_containedRels;
720 /*
721 * Recursively process the left and right subtrees
722 */
734 /*
735 * Check for conflicting refnames in left and right subtrees. Must do
736 * this because higher levels will assume I hand back a self-
737 * consistent namespace subtree.
738 */
741 /*
742 * Generate combined relation membership info for possible use by
743 * transformJoinOnClause below.
744 */
750 /*
751 * Extract column name and var lists from both subtrees
752 *
753 * Note: expandRTE returns new lists, safe for me to modify
754 */
760 /*
761 * Natural join does not explicitly specify columns; must generate
762 * columns to join. Need to run through the list of columns from each
763 * table or join result and match up the column names. Use the first
764 * table, and check every column in the second table for a match.
765 * (We'll check that the matches were unique later on.) The result of
766 * this step is a list of column names just like an explicitly-written
767 * USING list.
768 */
770 {
778 {
783 {
787 {
790 }
791 }
793 /* matched a right column? then keep as join column... */
796 }
799 }
801 /*
802 * Now transform the join qualifications, if any.
803 */
808 {
809 /*
810 * JOIN/USING (or NATURAL JOIN, as transformed above). Transform
811 * the list into an explicit ON-condition, and generate a list of
812 * merged result columns.
813 */
822 {
831 /* Check for USING(foo,foo) */
833 {
840 u_colname)));
841 }
843 /* Find it in left input */
846 {
850 {
855 u_colname)));
857 }
858 ndx++;
859 }
864 u_colname)));
866 /* Find it in right input */
869 {
873 {
878 u_colname)));
880 }
881 ndx++;
882 }
887 u_colname)));
898 l_colvar,
899 r_colvar));
900 }
903 l_usingvars,
904 r_usingvars);
905 }
907 {
908 /* User-written ON-condition; transform it */
911 my_relnamespace,
912 my_containedRels);
913 }
914 else
915 {
916 /* CROSS JOIN: no quals */
917 }
919 /* Add remaining columns from each side to the output columns */
931 /*
932 * Check alias (AS clause), if any.
933 */
935 {
937 {
943 }
944 }
946 /*
947 * Now build an RTE for the result of the join
948 */
950 res_colnames,
952 res_colvars,
956 /* assume new rte is at end */
963 /*
964 * Prepare returned namespace list. If the JOIN has an alias then it
965 * hides the contained RTEs as far as the relnamespace goes;
966 * otherwise, put the contained RTEs and *not* the JOIN into
967 * relnamespace.
968 */
970 {
973 }
974 else
977 /*
978 * Include join RTE in returned containedRels set
979 */
983 }
984 else
987 }
989 /*
990 * buildMergedJoinVar -
991 * generate a suitable replacement expression for a merged join column
992 */
996 {
997 Oid outcoltype;
998 int32 outcoltypmod;
1003 /*
1004 * Choose output type if input types are dissimilar.
1005 */
1009 {
1013 NULL);
1015 }
1017 {
1018 /* same type, but not same typmod */
1020 }
1022 /*
1023 * Insert coercion functions if needed. Note that a difference in typmod
1024 * can only happen if input has typmod but outcoltypmod is -1. In that
1025 * case we insert a RelabelType to clearly mark that result's typmod is
1026 * not same as input. We never need coerce_type_typmod.
1027 */
1035 COERCE_IMPLICIT_CAST);
1036 else
1046 COERCE_IMPLICIT_CAST);
1047 else
1050 /*
1051 * Choose what to emit
1052 */
1054 {
1057 /*
1058 * We can use either var; prefer non-coerced one if available.
1059 */
1064 else
1068 /* Always use left var */
1072 /* Always use right var */
1076 {
1077 /*
1078 * Here we must build a COALESCE expression to ensure that the
1079 * join output is non-null if either input is.
1080 */
1088 }
1093 }
1096 }
1099 /*
1100 * transformWhereClause -
1101 * Transform the qualification and make sure it is of type boolean.
1102 * Used for WHERE and allied clauses.
1103 *
1104 * constructName does not affect the semantics, but is used in error messages
1105 */
1106 Node *
1109 {
1120 }
1123 /*
1124 * transformLimitClause -
1125 * Transform the expression and make sure it is of type bigint.
1126 * Used for LIMIT and allied clauses.
1127 *
1128 * Note: as of Postgres 8.2, LIMIT expressions are expected to yield int8,
1129 * rather than int4 as before.
1130 *
1131 * constructName does not affect the semantics, but is used in error messages
1132 */
1133 Node *
1136 {
1146 /*
1147 * LIMIT can't refer to any vars or aggregates of the current query
1148 */
1150 {
1153 /* translator: %s is name of a SQL construct, eg LIMIT */
1155 constructName),
1158 }
1160 {
1163 /* translator: %s is name of a SQL construct, eg LIMIT */
1165 constructName),
1168 }
1171 }
1174 /*
1175 * findTargetlistEntry -
1176 * Returns the targetlist entry matching the given (untransformed) node.
1177 * If no matching entry exists, one is created and appended to the target
1178 * list as a "resjunk" node.
1179 *
1180 * node the ORDER BY, GROUP BY, or DISTINCT ON expression to be matched
1181 * tlist the target list (passed by reference so we can append to it)
1182 * clause identifies clause type being processed
1183 */
1186 {
1191 /*----------
1192 * Handle two special cases as mandated by the SQL92 spec:
1193 *
1194 * 1. Bare ColumnName (no qualifier or subscripts)
1195 * For a bare identifier, we search for a matching column name
1196 * in the existing target list. Multiple matches are an error
1197 * unless they refer to identical values; for example,
1198 * we allow SELECT a, a FROM table ORDER BY a
1199 * but not SELECT a AS b, b FROM table ORDER BY b
1200 * If no match is found, we fall through and treat the identifier
1201 * as an expression.
1202 * For GROUP BY, it is incorrect to match the grouping item against
1203 * targetlist entries: according to SQL92, an identifier in GROUP BY
1204 * is a reference to a column name exposed by FROM, not to a target
1205 * list column. However, many implementations (including pre-7.0
1206 * PostgreSQL) accept this anyway. So for GROUP BY, we look first
1207 * to see if the identifier matches any FROM column name, and only
1208 * try for a targetlist name if it doesn't. This ensures that we
1209 * adhere to the spec in the case where the name could be both.
1210 * DISTINCT ON isn't in the standard, so we can do what we like there;
1211 * we choose to make it work like ORDER BY, on the rather flimsy
1212 * grounds that ordinary DISTINCT works on targetlist entries.
1213 *
1214 * 2. IntegerConstant
1215 * This means to use the n'th item in the existing target list.
1216 * Note that it would make no sense to order/group/distinct by an
1217 * actual constant, so this does not create a conflict with our
1218 * extension to order/group by an expression.
1219 * GROUP BY column-number is not allowed by SQL92, but since
1220 * the standard has no other behavior defined for this syntax,
1221 * we may as well accept this common extension.
1222 *
1223 * Note that pre-existing resjunk targets must not be used in either case,
1224 * since the user didn't write them in his SELECT list.
1225 *
1226 * If neither special case applies, fall through to treat the item as
1227 * an expression.
1228 *----------
1229 */
1233 {
1238 {
1239 /*
1240 * In GROUP BY, we must prefer a match against a FROM-clause
1241 * column to one against the targetlist. Look to see if there is
1242 * a matching column. If so, fall through to let transformExpr()
1243 * do the rest. NOTE: if name could refer ambiguously to more
1244 * than one column name exposed by FROM, colNameToVar will
1245 * ereport(ERROR). That's just what we want here.
1246 *
1247 * Small tweak for 7.4.3: ignore matches in upper query levels.
1248 * This effectively changes the search order for bare names to (1)
1249 * local FROM variables, (2) local targetlist aliases, (3) outer
1250 * FROM variables, whereas before it was (1) (3) (2). SQL92 and
1251 * SQL99 do not allow GROUPing BY an outer reference, so this
1252 * breaks no cases that are legal per spec, and it seems a more
1253 * self-consistent behavior.
1254 */
1257 }
1260 {
1262 {
1267 {
1269 {
1274 /*------
1275 translator: first %s is name of a SQL construct, eg ORDER BY */
1279 }
1280 else
1282 /* Stay in loop to check for ambiguity */
1283 }
1284 }
1287 }
1288 }
1290 {
1299 /* translator: %s is name of a SQL construct, eg ORDER BY */
1306 {
1310 {
1313 }
1314 }
1317 /* translator: %s is name of a SQL construct, eg ORDER BY */
1321 }
1323 /*
1324 * Otherwise, we have an expression (this is a Postgres extension not
1325 * found in SQL92). Convert the untransformed node to a transformed
1326 * expression, and search for a match in the tlist. NOTE: it doesn't
1327 * really matter whether there is more than one match. Also, we are
1328 * willing to match a resjunk target here, though the above cases must
1329 * ignore resjunk targets.
1330 */
1334 {
1339 }
1341 /*
1342 * If no matches, construct a new target entry which is appended to the
1343 * end of the target list. This target is given resjunk = TRUE so that it
1344 * will not be projected into the final tuple.
1345 */
1351 }
1353 /*
1354 * transformGroupClause -
1355 * transform a GROUP BY clause
1356 *
1357 * GROUP BY items will be added to the targetlist (as resjunk columns)
1358 * if not already present, so the targetlist must be passed by reference.
1359 */
1360 List *
1363 {
1368 {
1376 /* Eliminate duplicates (GROUP BY x, x) */
1380 /*
1381 * If the GROUP BY tlist entry also appears in ORDER BY, copy operator
1382 * info from the (first) matching ORDER BY item. This means that if
1383 * you write something like "GROUP BY foo ORDER BY foo USING <<<", the
1384 * GROUP BY operation silently takes on the equality semantics implied
1385 * by the ORDER BY. There are two reasons to do this: it improves
1386 * the odds that we can implement both GROUP BY and ORDER BY with a
1387 * single sort step, and it allows the user to choose the equality
1388 * semantics used by GROUP BY, should she be working with a datatype
1389 * that has more than one equality operator.
1390 */
1392 {
1396 {
1400 {
1404 }
1405 }
1406 }
1408 /*
1409 * If no match in ORDER BY, just add it to the result using
1410 * default sort/group semantics.
1411 */
1417 }
1420 }
1422 /*
1423 * transformSortClause -
1424 * transform an ORDER BY clause
1425 *
1426 * ORDER BY items will be added to the targetlist (as resjunk columns)
1427 * if not already present, so the targetlist must be passed by reference.
1428 */
1429 List *
1434 {
1439 {
1448 resolveUnknown);
1449 }
1452 }
1454 /*
1455 * transformDistinctClause -
1456 * transform a DISTINCT clause
1457 *
1458 * Since we may need to add items to the query's targetlist, that list
1459 * is passed by reference.
1460 *
1461 * As with GROUP BY, we absorb the sorting semantics of ORDER BY as much as
1462 * possible into the distinctClause. This avoids a possible need to re-sort,
1463 * and allows the user to choose the equality semantics used by DISTINCT,
1464 * should she be working with a datatype that has more than one equality
1465 * operator.
1466 */
1467 List *
1470 {
1475 /*
1476 * The distinctClause should consist of all ORDER BY items followed
1477 * by all other non-resjunk targetlist items. There must not be any
1478 * resjunk ORDER BY items --- that would imply that we are sorting
1479 * by a value that isn't necessarily unique within a DISTINCT group,
1480 * so the results wouldn't be well-defined. This construction
1481 * ensures we follow the rule that sortClause and distinctClause match;
1482 * in fact the sortClause will always be a prefix of distinctClause.
1483 *
1484 * Note a corner case: the same TLE could be in the ORDER BY list
1485 * multiple times with different sortops. We have to include it in
1486 * the distinctClause the same way to preserve the prefix property.
1487 * The net effect will be that the TLE value will be made unique
1488 * according to both sortops.
1489 */
1491 {
1502 }
1504 /*
1505 * Now add any remaining non-resjunk tlist items, using default
1506 * sort/group semantics for their data types.
1507 */
1509 {
1518 }
1521 }
1523 /*
1524 * transformDistinctOnClause -
1525 * transform a DISTINCT ON clause
1526 *
1527 * Since we may need to add items to the query's targetlist, that list
1528 * is passed by reference.
1529 *
1530 * As with GROUP BY, we absorb the sorting semantics of ORDER BY as much as
1531 * possible into the distinctClause. This avoids a possible need to re-sort,
1532 * and allows the user to choose the equality semantics used by DISTINCT,
1533 * should she be working with a datatype that has more than one equality
1534 * operator.
1535 */
1536 List *
1539 {
1546 /*
1547 * Add all the DISTINCT ON expressions to the tlist (if not already
1548 * present, they are added as resjunk items). Assign sortgroupref
1549 * numbers to them, and make a list of these numbers. (NB: we rely
1550 * below on the sortgrouprefs list being one-for-one with the original
1551 * distinctlist. Also notice that we could have duplicate DISTINCT ON
1552 * expressions and hence duplicate entries in sortgrouprefs.)
1553 */
1555 {
1564 }
1566 /*
1567 * If the user writes both DISTINCT ON and ORDER BY, adopt the
1568 * sorting semantics from ORDER BY items that match DISTINCT ON
1569 * items, and also adopt their column sort order. We insist that
1570 * the distinctClause and sortClause match, so throw error if we
1571 * find the need to add any more distinctClause items after we've
1572 * skipped an ORDER BY item that wasn't in DISTINCT ON.
1573 */
1576 {
1580 {
1587 sortgrouprefs,
1588 distinctlist))));
1589 else
1591 }
1592 else
1594 }
1596 /*
1597 * Now add any remaining DISTINCT ON items, using default sort/group
1598 * semantics for their data types. (Note: this is pretty questionable;
1599 * if the ORDER BY list doesn't include all the DISTINCT ON items and more
1600 * besides, you certainly aren't using DISTINCT ON in the intended way,
1601 * and you probably aren't going to get consistent results. It might be
1602 * better to throw an error or warning here. But historically we've
1603 * allowed it, so keep doing so.)
1604 */
1606 {
1622 }
1625 }
1627 /*
1628 * get_matching_location
1629 * Get the exprLocation of the exprs member corresponding to the
1630 * (first) member of sortgrouprefs that equals sortgroupref.
1631 *
1632 * This is used so that we can point at a troublesome DISTINCT ON entry.
1633 * (Note that we need to use the original untransformed DISTINCT ON list
1634 * item, as whatever TLE it corresponds to will very possibly have a
1635 * parse location pointing to some matching entry in the SELECT list
1636 * or ORDER BY list.)
1637 */
1638 static int
1640 {
1645 {
1648 }
1649 /* if no match, caller blew it */
1652 }
1654 /*
1655 * addTargetToSortList
1656 * If the given targetlist entry isn't already in the SortGroupClause
1657 * list, add it to the end of the list, using the given sort ordering
1658 * info.
1659 *
1660 * If resolveUnknown is TRUE, convert TLEs of type UNKNOWN to TEXT. If not,
1661 * do nothing (which implies the search for a sort operator will fail).
1662 * pstate should be provided if resolveUnknown is TRUE, but can be NULL
1663 * otherwise.
1664 *
1665 * Returns the updated SortGroupClause list.
1666 */
1671 {
1673 Oid sortop;
1674 Oid eqop;
1677 ParseCallbackState pcbstate;
1679 /* if tlist item is an UNKNOWN literal, change it to TEXT */
1681 {
1684 COERCION_IMPLICIT,
1685 COERCE_IMPLICIT_CAST,
1688 }
1690 /*
1691 * Rather than clutter the API of get_sort_group_operators and the other
1692 * functions we're about to use, make use of error context callback to
1693 * mark any error reports with a parse position. We point to the operator
1694 * location if present, else to the expression being sorted. (NB: use
1695 * the original untransformed expression here; the TLE entry might well
1696 * point at a duplicate expression in the regular SELECT list.)
1697 */
1703 /* determine the sortop, eqop, and directionality */
1705 {
1722 restype,
1723 restype,
1726 /*
1727 * Verify it's a valid ordering operator, fetch the corresponding
1728 * equality operator, and determine whether to consider it like
1729 * ASC or DESC.
1730 */
1745 }
1749 /* avoid making duplicate sortlist entries */
1751 {
1760 {
1762 /* NULLS FIRST is default for DESC; other way for ASC */
1775 }
1778 }
1781 }
1783 /*
1784 * addTargetToGroupList
1785 * If the given targetlist entry isn't already in the SortGroupClause
1786 * list, add it to the end of the list, using default sort/group
1787 * semantics.
1788 *
1789 * This is very similar to addTargetToSortList, except that we allow the
1790 * case where only a grouping (equality) operator can be found, and that
1791 * the TLE is considered "already in the list" if it appears there with any
1792 * sorting semantics.
1793 *
1794 * location is the parse location to be fingered in event of trouble. Note
1795 * that we can't rely on exprLocation(tle->expr), because that might point
1796 * to a SELECT item that matches the GROUP BY item; it'd be pretty confusing
1797 * to report such a location.
1798 *
1799 * If resolveUnknown is TRUE, convert TLEs of type UNKNOWN to TEXT. If not,
1800 * do nothing (which implies the search for an equality operator will fail).
1801 * pstate should be provided if resolveUnknown is TRUE, but can be NULL
1802 * otherwise.
1803 *
1804 * Returns the updated SortGroupClause list.
1805 */
1810 {
1812 Oid sortop;
1813 Oid eqop;
1815 /* if tlist item is an UNKNOWN literal, change it to TEXT */
1817 {
1820 COERCION_IMPLICIT,
1821 COERCE_IMPLICIT_CAST,
1824 }
1826 /* avoid making duplicate grouplist entries */
1828 {
1830 ParseCallbackState pcbstate;
1834 /* determine the eqop and optional sortop */
1847 }
1850 }
1852 /*
1853 * assignSortGroupRef
1854 * Assign the targetentry an unused ressortgroupref, if it doesn't
1855 * already have one. Return the assigned or pre-existing refnumber.
1856 *
1857 * 'tlist' is the targetlist containing (or to contain) the given targetentry.
1858 */
1859 Index
1861 {
1862 Index maxRef;
1868 /* easiest way to pick an unused refnumber: max used + 1 */
1871 {
1876 }
1879 }
1881 /*
1882 * targetIsInSortList
1883 * Is the given target item already in the sortlist?
1884 * If sortop is not InvalidOid, also test for a match to the sortop.
1885 *
1886 * It is not an oversight that this function ignores the nulls_first flag.
1887 * We check sortop when determining if an ORDER BY item is redundant with
1888 * earlier ORDER BY items, because it's conceivable that "ORDER BY
1889 * foo USING <, foo USING <<<" is not redundant, if <<< distinguishes
1890 * values that < considers equal. We need not check nulls_first
1891 * however, because a lower-order column with the same sortop but
1892 * opposite nulls direction is redundant. Also, we can consider
1893 * ORDER BY foo ASC, foo DESC redundant, so check for a commutator match.
1894 *
1895 * Works for both ordering and grouping lists (sortop would normally be
1896 * InvalidOid when considering grouping). Note that the main reason we need
1897 * this routine (and not just a quick test for nonzeroness of ressortgroupref)
1898 * is that a TLE might be in only one of the lists.
1899 */
1900 bool
1902 {
1906 /* no need to scan list if tle has no marker */
1911 {
1919 }
1921 }