elein <[EMAIL PROTECTED]> writes:
> Attached is a patch to parse_oper.c which essentially does the
> following. The major change is in binary_oper_exact().
> Instead of checking only one level of the basetype it checks
> all possible combinations of type and parent types for
> an exact match (only).
I'm going to object to this just on the grounds of the extent to which
it will slow down parsing. I also think it completely destroys the
logical structure of the lookup code: binary_operator_exact is supposed
to find exact matches, nothing else. Approximate matches should be
sought only after that's failed. Also, why aren't the unary-operator
cases handled? And why are you making the semantics of operator lookup
different from function lookup?
The correct place to be fooling with this is in func_select_candidate(),
whose initial smashing of domains to base types is the proximate cause
of the problems you are complaining of. I think what you'd need is to
get rid of that blunt instrument and instead put in some kind of logic
to prefer matches to "higher up" domains over matches to the base type,
while not entirely excluding the latter. func_select_candidate()
already has a lot of heuristics about preferring some matches over
others, and should be able to deal with one more.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
