elein <[EMAIL PROTECTED]> writes:
> Operators have the single distinction from functions in that when one argument
> has an unknown type, then an exact match is tried with the unknown arg
> type set to the known type. This code has always been in there.
Yeah, but it's just a fast special case of the generic UNKNOWN handling
in func_select_candidate. The domain special case in binary_oper_exact
is a wart --- ideally it should be excised not enlarged ;-). It's
mainly there because we didn't want to complicate func_select_candidate
to deal with domains. If you're going to do the latter anyway, it may
be possible to remove the domain special case in binary_oper_exact.
In any case, the patch is very poorly thought through: it will not
behave reasonably if there are multiple levels of domains with different
candidate operators attached to each domain. (I can tell you have not
tested this: getBaseType drills all the way down, so mk_oper_arg_list
isn't doing what you think.) You need some kind of policy as to which
candidate is more preferable if some are "closer" types on one input and
some are "closer" on another, and binary_oper_exact is not the place for
that kind of decision. It's only supposed to be a fast short-circuit
for the cases of exact matches and exact-after-substituting-other-type-
for-UNKNOWN matches. If you make it do more you'll be upsetting some
careful compromises in the type resolution rules.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
