| blob | 8ea76ab94f8c86d4d23a56ffb632923aa65ddde7 |
1 /*-------------------------------------------------------------------------
2 *
3 * parse_func.c
4 * handle function calls in parser
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 */
40 /*
41 * Parse a function call
42 *
43 * For historical reasons, Postgres tries to treat the notations tab.col
44 * and col(tab) as equivalent: if a single-argument function call has an
45 * argument of complex type and the (unqualified) function name matches
46 * any attribute of the type, we take it as a column projection. Conversely
47 * a function of a single complex-type argument can be written like a
48 * column reference, allowing functions to act like computed columns.
49 *
50 * Hence, both cases come through here. The is_column parameter tells us
51 * which syntactic construct is actually being dealt with, but this is
52 * intended to be used only to deliver an appropriate error message,
53 * not to affect the semantics. When is_column is true, we should have
54 * a single argument (the putative table), unqualified function name
55 * equal to the column name, and no aggregate or variadic decoration.
56 *
57 * The argument expressions (in fargs) must have been transformed already.
58 */
59 Node *
63 {
64 Oid rettype;
65 Oid funcid;
77 FuncDetailCode fdresult;
79 /*
80 * Most of the rest of the parser just assumes that functions do not have
81 * more than FUNC_MAX_ARGS parameters. We have to test here to protect
82 * against array overruns, etc. Of course, this may not be a function,
83 * but the test doesn't hurt.
84 */
90 FUNC_MAX_ARGS,
91 FUNC_MAX_ARGS),
94 /*
95 * Extract arg type info in preparation for function lookup.
96 *
97 * If any arguments are Param markers of type VOID, we discard them from
98 * the parameter list. This is a hack to allow the JDBC driver to not
99 * have to distinguish "input" and "output" parameter symbols while
100 * parsing function-call constructs. We can't use foreach() because we
101 * may modify the list ...
102 */
105 {
112 {
115 }
118 }
121 {
124 }
126 /*
127 * Check for column projection: if function has one argument, and that
128 * argument is of complex type, and function name is not qualified, then
129 * the "function call" could be a projection. We also check that there
130 * wasn't any aggregate or variadic decoration.
131 */
134 {
138 {
141 first_arg,
142 location);
146 /*
147 * If ParseComplexProjection doesn't recognize it as a projection,
148 * just press on.
149 */
150 }
151 }
153 /*
154 * Okay, it's not a column projection, so it must really be a function.
155 * func_get_detail looks up the function in the catalogs, does
156 * disambiguation for polymorphic functions, handles inheritance, and
157 * returns the funcid and type and set or singleton status of the
158 * function's return value. It also returns the true argument types to
159 * the function. In the case of a variadic function call, the reported
160 * "true" types aren't really what is in pg_proc: the variadic argument is
161 * replaced by a suitable number of copies of its element type. We'll fix
162 * it up below. We may also have to deal with default arguments.
163 */
169 {
170 /*
171 * We interpreted it as a type coercion. coerce_type can handle these
172 * cases, so why duplicate code...
173 */
177 }
179 {
180 /*
181 * Normal function found; was there anything indicating it must be an
182 * aggregate?
183 */
203 }
206 {
207 /*
208 * Oops. Time to die.
209 *
210 * If we are dealing with the attribute notation rel.function, give an
211 * error message that is appropriate for that case.
212 */
214 {
218 location);
219 }
221 /*
222 * Else generate a detailed complaint for a function
223 */
229 actual_arg_types)),
233 else
238 actual_arg_types)),
242 }
244 /*
245 * If there are default arguments, we have to include their types in
246 * actual_arg_types for the purpose of checking generic type consistency.
247 * However, we do NOT put them into the generated parse node, because
248 * their actual values might change before the query gets run. The
249 * planner has to insert the up-to-date values at plan time.
250 */
253 {
256 /* probably shouldn't happen ... */
262 FUNC_MAX_ARGS,
263 FUNC_MAX_ARGS),
267 }
269 /*
270 * enforce consistency with polymorphic argument and return types,
271 * possibly adjusting return type or declared_arg_types (which will be
272 * used as the cast destination by make_fn_arguments)
273 */
275 declared_arg_types,
276 nargsplusdefs,
277 rettype,
280 /* perform the necessary typecasting of arguments */
283 /*
284 * If it's a variadic function call, transform the last nvargs arguments
285 * into an array --- unless it's an "any" variadic.
286 */
288 {
298 /* assume all the variadic arguments were coerced to the same type */
311 }
313 /* build the appropriate output structure */
315 {
326 }
328 {
329 /* aggregate function */
339 /*
340 * Reject attempt to call a parameterless aggregate without (*)
341 * syntax. This is mere pedantry but some folks insisted ...
342 */
356 /* parse_agg.c does additional aggregate-specific processing */
360 }
361 else
362 {
363 /* window function */
366 /*
367 * True window functions must be called with a window definition.
368 */
378 /* winref will be set by transformWindowFuncCall */
383 /*
384 * agg_star is allowed for aggregate functions but distinct isn't
385 */
392 /*
393 * Reject attempt to call a parameterless aggregate without (*)
394 * syntax. This is mere pedantry but some folks insisted ...
395 */
409 /* parse_agg.c does additional window-func-specific processing */
413 }
416 }
419 /* func_match_argtypes()
420 *
421 * Given a list of candidate functions (having the right name and number
422 * of arguments) and an array of input datatype OIDs, produce a shortlist of
423 * those candidates that actually accept the input datatypes (either exactly
424 * or by coercion), and return the number of such candidates.
425 *
426 * Note that can_coerce_type will assume that UNKNOWN inputs are coercible to
427 * anything, so candidates will not be eliminated on that basis.
428 *
429 * NB: okay to modify input list structure, as long as we find at least
430 * one match. If no match at all, the list must remain unmodified.
431 */
432 int
435 FuncCandidateList raw_candidates,
437 {
438 FuncCandidateList current_candidate;
439 FuncCandidateList next_candidate;
447 {
450 COERCION_IMPLICIT))
451 {
454 ncandidates++;
455 }
456 }
462 /* func_select_candidate()
463 * Given the input argtype array and more than one candidate
464 * for the function, attempt to resolve the conflict.
465 *
466 * Returns the selected candidate if the conflict can be resolved,
467 * otherwise returns NULL.
468 *
469 * Note that the caller has already determined that there is no candidate
470 * exactly matching the input argtypes, and has pruned away any "candidates"
471 * that aren't actually coercion-compatible with the input types.
472 *
473 * This is also used for resolving ambiguous operator references. Formerly
474 * parse_oper.c had its own, essentially duplicate code for the purpose.
475 * The following comments (formerly in parse_oper.c) are kept to record some
476 * of the history of these heuristics.
477 *
478 * OLD COMMENTS:
479 *
480 * This routine is new code, replacing binary_oper_select_candidate()
481 * which dates from v4.2/v1.0.x days. It tries very hard to match up
482 * operators with types, including allowing type coercions if necessary.
483 * The important thing is that the code do as much as possible,
484 * while _never_ doing the wrong thing, where "the wrong thing" would
485 * be returning an operator when other better choices are available,
486 * or returning an operator which is a non-intuitive possibility.
487 * - thomas 1998-05-21
488 *
489 * The comments below came from binary_oper_select_candidate(), and
490 * illustrate the issues and choices which are possible:
491 * - thomas 1998-05-20
492 *
493 * current wisdom holds that the default operator should be one in which
494 * both operands have the same type (there will only be one such
495 * operator)
496 *
497 * 7.27.93 - I have decided not to do this; it's too hard to justify, and
498 * it's easy enough to typecast explicitly - avi
499 * [the rest of this routine was commented out since then - ay]
500 *
501 * 6/23/95 - I don't complete agree with avi. In particular, casting
502 * floats is a pain for users. Whatever the rationale behind not doing
503 * this is, I need the following special case to work.
504 *
505 * In the WHERE clause of a query, if a float is specified without
506 * quotes, we treat it as float8. I added the float48* operators so
507 * that we can operate on float4 and float8. But now we have more than
508 * one matching operator if the right arg is unknown (eg. float
509 * specified with quotes). This break some stuff in the regression
510 * test where there are floats in quotes not properly casted. Below is
511 * the solution. In addition to requiring the operator operates on the
512 * same type for both operands [as in the code Avi originally
513 * commented out], we also require that the operators be equivalent in
514 * some sense. (see equivalentOpersAfterPromotion for details.)
515 * - ay 6/95
516 */
517 FuncCandidateList
520 FuncCandidateList candidates)
521 {
522 FuncCandidateList current_candidate;
523 FuncCandidateList last_candidate;
525 Oid current_type;
529 nmatch;
532 current_category;
537 /* protect local fixed-size arrays */
543 FUNC_MAX_ARGS,
544 FUNC_MAX_ARGS)));
546 /*
547 * If any input types are domains, reduce them to their base types. This
548 * ensures that we will consider functions on the base type to be "exact
549 * matches" in the exact-match heuristic; it also makes it possible to do
550 * something useful with the type-category heuristics. Note that this
551 * makes it difficult, but not impossible, to use functions declared to
552 * take a domain as an input datatype. Such a function will be selected
553 * over the base-type function only if it is an exact match at all
554 * argument positions, and so was already chosen by our caller.
555 */
559 /*
560 * Run through all candidates and keep those with the most matches on
561 * exact types. Keep all candidates if none match.
562 */
569 {
573 {
576 nmatch++;
577 }
579 /* take this one as the best choice so far? */
581 {
586 }
587 /* no worse than the last choice, so keep this one too? */
589 {
592 ncandidates++;
593 }
594 /* otherwise, don't bother keeping this one... */
595 }
603 /*
604 * Still too many candidates? Now look for candidates which have either
605 * exact matches or preferred types at the args that will require
606 * coercion. (Restriction added in 7.4: preferred type must be of same
607 * category as input type; give no preference to cross-category
608 * conversions to preferred types.) Keep all candidates if none match.
609 */
618 {
622 {
624 {
627 nmatch++;
628 }
629 }
632 {
637 }
639 {
642 ncandidates++;
643 }
644 }
652 /*
653 * Still too many candidates? Try assigning types for the unknown columns.
654 *
655 * NOTE: for a binary operator with one unknown and one non-unknown input,
656 * we already tried the heuristic of looking for a candidate with the
657 * known input type on both sides (see binary_oper_exact()). That's
658 * essentially a special case of the general algorithm we try next.
659 *
660 * We do this by examining each unknown argument position to see if we can
661 * determine a "type category" for it. If any candidate has an input
662 * datatype of STRING category, use STRING category (this bias towards
663 * STRING is appropriate since unknown-type literals look like strings).
664 * Otherwise, if all the candidates agree on the type category of this
665 * argument position, use that category. Otherwise, fail because we
666 * cannot determine a category.
667 *
668 * If we are able to determine a type category, also notice whether any of
669 * the candidates takes a preferred datatype within the category.
670 *
671 * Having completed this examination, remove candidates that accept the
672 * wrong category at any unknown position. Also, if at least one
673 * candidate accepted a preferred type at a position, remove candidates
674 * that accept non-preferred types.
675 *
676 * If we are down to one candidate at the end, we win.
677 */
680 {
692 {
699 {
700 /* first candidate */
703 }
705 {
706 /* more candidates in same category */
708 }
709 else
710 {
711 /* category conflict! */
713 {
714 /* STRING always wins if available */
717 }
718 else
719 {
720 /*
721 * Remember conflict, but keep going (might find STRING)
722 */
724 }
725 }
726 }
728 {
729 /* Failed to resolve category conflict at this position */
732 }
733 }
736 {
737 /* Strip non-matching candidates */
743 {
748 {
756 {
759 }
761 {
764 }
765 }
767 {
768 /* keep this candidate */
770 ncandidates++;
771 }
772 else
773 {
774 /* forget this candidate */
777 else
779 }
780 }
783 }
792 /* func_get_detail()
793 *
794 * Find the named function in the system catalogs.
795 *
796 * Attempt to find the named function in the system catalogs with
797 * arguments exactly as specified, so that the normal case (exact match)
798 * is as quick as possible.
799 *
800 * If an exact match isn't found:
801 * 1) check for possible interpretation as a type coercion request
802 * 2) apply the ambiguous-function resolution rules
803 *
804 * Note: we rely primarily on nargs/argtypes as the argument description.
805 * The actual expression node list is passed in fargs so that we can check
806 * for type coercion of a constant. Some callers pass fargs == NIL
807 * indicating they don't want that check made.
808 */
809 FuncDetailCode
822 {
823 FuncCandidateList raw_candidates;
824 FuncCandidateList best_candidate;
826 /* initialize output arguments to silence compiler warnings */
835 /* Get list of possible candidates from namespace search */
839 /*
840 * Quickly check if there is an exact match to the input datatypes (there
841 * can be only one)
842 */
846 {
849 }
852 {
853 /*
854 * If we didn't find an exact match, next consider the possibility
855 * that this is really a type-coercion request: a single-argument
856 * function call where the function name is a type name. If so, and
857 * if the coercion path is RELABELTYPE or COERCEVIAIO, then go ahead
858 * and treat the "function call" as a coercion.
859 *
860 * This interpretation needs to be given higher priority than
861 * interpretations involving a type coercion followed by a function
862 * call, otherwise we can produce surprising results. For example, we
863 * want "text(varchar)" to be interpreted as a simple coercion, not as
864 * "text(name(varchar))" which the code below this point is entirely
865 * capable of selecting.
866 *
867 * We also treat a coercion of a previously-unknown-type literal
868 * constant to a specific type this way.
869 *
870 * The reason we reject COERCION_PATH_FUNC here is that we expect the
871 * cast implementation function to be named after the target type.
872 * Thus the function will be found by normal lookup if appropriate.
873 *
874 * The reason we reject COERCION_PATH_ARRAYCOERCE is mainly that you
875 * can't write "foo[] (something)" as a function call. In theory
876 * someone might want to invoke it as "_foo (something)" but we have
877 * never supported that historically, so we can insist that people
878 * write it as a normal cast instead. Lack of historical support is
879 * also the reason for not considering composite-type casts here.
880 *
881 * NB: it's important that this code does not exceed what coerce_type
882 * can do, because the caller will try to apply coerce_type if we
883 * return FUNCDETAIL_COERCION. If we return that result for something
884 * coerce_type can't handle, we'll cause infinite recursion between
885 * this module and coerce_type!
886 */
888 {
892 {
898 {
899 /* always treat typename('literal') as coercion */
901 }
902 else
903 {
904 CoercionPathType cpathtype;
905 Oid cfuncid;
908 COERCION_EXPLICIT,
912 }
915 {
916 /* Treat it as a type coercion */
923 }
924 }
925 }
927 /*
928 * didn't find an exact match, so now try to match up candidates...
929 */
931 {
932 FuncCandidateList current_candidates;
936 argtypes,
937 raw_candidates,
940 /* one match only? then run with it... */
944 /*
945 * multiple candidates? then better decide or throw an error...
946 */
948 {
950 argtypes,
951 current_candidates);
953 /*
954 * If we were able to choose a best candidate, we're done.
955 * Otherwise, ambiguous function call.
956 */
959 }
960 }
961 }
964 {
965 HeapTuple ftup;
966 Form_pg_proc pform;
967 FuncDetailCode result;
969 /*
970 * If expanding variadics or defaults, the "best candidate" might
971 * represent multiple equivalently good functions; treat this case as
972 * ambiguous.
973 */
990 /* fetch default args if caller wants 'em */
992 {
994 {
995 Datum proargdefaults;
1001 /* shouldn't happen, FuncnameGetCandidates messed up */
1006 Anum_pg_proc_proargdefaults,
1013 /* Delete any unused defaults from the returned list */
1018 }
1019 else
1021 }
1026 else
1030 }
1033 }
1036 /*
1037 * make_fn_arguments()
1038 *
1039 * Given the actual argument expressions for a function, and the desired
1040 * input types for the function, add any necessary typecasting to the
1041 * expression tree. Caller should already have verified that casting is
1042 * allowed.
1043 *
1044 * Caution: given argument list is modified in-place.
1045 *
1046 * As with coerce_type, pstate may be NULL if no special unknown-Param
1047 * processing is wanted.
1048 */
1049 void
1054 {
1059 {
1060 /* types don't match? then force coercion using a function call... */
1062 {
1067 COERCION_IMPLICIT,
1068 COERCE_IMPLICIT_CAST,
1070 }
1071 i++;
1072 }
1073 }
1075 /*
1076 * FuncNameAsType -
1077 * convenience routine to see if a function name matches a type name
1078 *
1079 * Returns the OID of the matching type, or InvalidOid if none. We ignore
1080 * shell types and complex types.
1081 */
1082 static Oid
1084 {
1085 Oid result;
1086 Type typtup;
1095 else
1100 }
1102 /*
1103 * ParseComplexProjection -
1104 * handles function calls with a single argument that is of complex type.
1105 * If the function call is actually a column projection, return a suitably
1106 * transformed expression tree. If not, return NULL.
1107 */
1111 {
1112 TupleDesc tupdesc;
1115 /*
1116 * Special case for whole-row Vars so that we can resolve (foo.*).bar even
1117 * when foo is a reference to a subselect, join, or RECORD function. A
1118 * bonus is that we avoid generating an unnecessary FieldSelect; our
1119 * result can omit the whole-row Var and just be a Var for the selected
1120 * field.
1121 *
1122 * This case could be handled by expandRecordVariable, but it's more
1123 * efficient to do it this way when possible.
1124 */
1127 {
1133 /* Return a Var if funcname matches a column, else NULL */
1135 }
1137 /*
1138 * Else do it the hard way with get_expr_result_type().
1139 *
1140 * If it's a Var of type RECORD, we have to work even harder: we have to
1141 * find what the Var refers to, and pass that to get_expr_result_type.
1142 * That task is handled by expandRecordVariable().
1143 */
1152 {
1157 {
1158 /* Success, so generate a FieldSelect expression */
1166 }
1167 }
1170 }
1172 /*
1173 * helper routine for delivering "column does not exist" error message
1174 */
1175 static void
1178 {
1183 {
1184 /* Reference the RTE by alias not by actual table name */
1193 }
1194 else
1195 {
1196 /* Have to do it by reference to the type of the expression */
1209 attname),
1211 else
1218 }
1219 }
1221 /*
1222 * funcname_signature_string
1223 * Build a string representing a function name, including arg types.
1224 * The result is something like "foo(integer)".
1225 *
1226 * This is typically used in the construction of function-not-found error
1227 * messages.
1228 */
1232 {
1233 StringInfoData argbuf;
1241 {
1245 }
1250 }
1252 /*
1253 * func_signature_string
1254 * As above, but function name is passed as a qualified name list.
1255 */
1258 {
1261 }
1263 /*
1264 * LookupFuncName
1265 * Given a possibly-qualified function name and a set of argument types,
1266 * look up the function.
1267 *
1268 * If the function name is not schema-qualified, it is sought in the current
1269 * namespace search path.
1270 *
1271 * If the function is not found, we return InvalidOid if noError is true,
1272 * else raise an error.
1273 */
1274 Oid
1276 {
1277 FuncCandidateList clist;
1282 {
1286 }
1295 }
1297 /*
1298 * LookupTypeNameOid
1299 * Convenience routine to look up a type, silently accepting shell types
1300 */
1301 static Oid
1303 {
1304 Oid result;
1305 Type typtup;
1316 }
1318 /*
1319 * LookupFuncNameTypeNames
1320 * Like LookupFuncName, but the argument types are specified by a
1321 * list of TypeName nodes.
1322 */
1323 Oid
1325 {
1337 FUNC_MAX_ARGS,
1338 FUNC_MAX_ARGS)));
1342 {
1347 }
1350 }
1352 /*
1353 * LookupAggNameTypeNames
1354 * Find an aggregate function given a name and list of TypeName nodes.
1355 *
1356 * This is almost like LookupFuncNameTypeNames, but the error messages refer
1357 * to aggregates rather than plain functions, and we verify that the found
1358 * function really is an aggregate.
1359 */
1360 Oid
1362 {
1367 Oid oid;
1368 HeapTuple ftup;
1369 Form_pg_proc pform;
1377 FUNC_MAX_ARGS,
1378 FUNC_MAX_ARGS)));
1382 {
1386 i++;
1387 }
1392 {
1400 else
1406 }
1408 /* Make sure it's an aggregate */
1417 {
1421 /* we do not use the (*) notation for functions... */
1427 }
1432 }