Re: argtype_inherit() is dead code - Mailing list pgsql-hackers

Are you saying that the code was supposed "unflatten" the
arguments of a function into a possible composite type taking into
consideration the possible inheritance information of the
composite type?

elein

On Fri, Apr 15, 2005 at 08:04:36PM -0400, Tom Lane wrote:
> 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 majordomo@postgresql.org)
>