In parse_func.c there are routines argtype_inherit() and gen_cross_product() that date from Berkeley days. The comments explain their reason for existence thus:
* This function is used to handle resolution of function calls when * there is no match to the given argument types, but there might be * matches based on considering complex types as members of their * superclass types (parent classes). * * It takes an array of input type ids. For each type id in the array * that's a complex type (a class), it walks up the inheritance tree, * finding all superclasses of that type. A vector of new Oid type * arrays is returned to the caller, listing possible alternative * interpretations of the input typeids as members of their superclasses * rather than the actually given argument types. The vector is * terminated by a NULL pointer. * * The order of this vector is as follows: all superclasses of the * rightmost complex class are explored first. The exploration * continues from right to left. This policy means that we favor * keeping the leftmost argument type as low in the inheritance tree * as possible. This is intentional; it is exactly what we need to * do for method dispatch. * * The vector does not include the case where no complex classes have * been promoted, since that was already tried before this routine * got called. I realized that this is effectively dead code: although it can be executed, it can never produce any useful results. The reason is that can_coerce_type() already knows that inherited rowtypes can be promoted to their parent rowtypes, and it considers that a legal implicit coercion. This means that any possible function matches based on promoting child rowtypes to ancestors were found in func_get_detail()'s first pass. If there is exactly one match then it will be taken as the correct answer and returned without calling argtype_inherit(). If there is more than one match then func_get_detail() will fail (return FUNCDETAIL_MULTIPLE), again without calling argtype_inherit(). The only way to reach argtype_inherit() is if there are *no* ancestor matches, which means that the function is a very expensive no-op that we execute just before throwing an error. I'm strongly tempted to just rip out argtype_inherit() and gen_cross_product(). Even if we suppose that we might want to resurrect the claimed functionality someday, I don't think it could be made to work this way. You'd have to put the knowledge into func_select_candidate() instead, else there'd be very weird interactions with the heuristics for resolving non-complex input argument types. Thoughts? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])