Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
Wouldn't it make sense to prefer operators/functions earlier in the search
path for resolving ambiguity. So if you had plus(int4, int4) in my
schema and plus(int8, int8) in system, and they'd otherwise cause an
ambiguity failure for the query, use the plus(int4, int4) on mine. It
seems not too far from having the search path shadow later exact matches.
Given the complexity of the resolution rules (cf.
http://developer.postgresql.org/docs/postgres/typeconv.html),
it's not clear that we can determine exactly which "later" entry ought
to be blamed for causing a resolution failure. I'd be interested to
hear Lockhart's opinion on this --- but my gut feeling is we don't
want to go there. The resolution rules are already complicated enough,
and I think layering an additional mechanism like that onto them might
make the behavior totally unpredictable.
Another problem is that this would probably cause earlier namespace
entries to be over-preferred. For example, suppose that the system
namespace has plus(int4,int4) and plus(int8,int8) and you choose to
define plus(int4,int8) locally. I believe you'd suddenly find yours
being used for *any* cross-datatype addit
ion, including cases that
had nothing obvious to do with either int4 or int8 ...
This is a good example. The other option is to use name, arg1, arg2...
as a hunt path for function call resolution. This would depend on when datatype
promotion is occuring (i.e. int4 to int8, int8 to int4, etc... )