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 addition, including cases that
had nothing obvious to do with either int4 or int8 ...
regards, tom lane
