Re: argtype_inherit() is dead code
От | elein@varlena.com (elein) |
---|---|
Тема | Re: argtype_inherit() is dead code |
Дата | |
Msg-id | 20050416173234.GP5278@varlena.com обсуждение исходный текст |
Ответ на | argtype_inherit() is dead code (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: argtype_inherit() is dead code
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | 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) >
В списке pgsql-hackers по дате отправления: