On Wed, 23 Jan 2002, Tom Lane wrote:
> 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 ...
Well, what I'd been thinking of would have been similar to anywhere it
says "If only one candidate matches", becoming "If the earliest search
path entry with at least one candidate matching has only one
matching candidate ..." But that would cause the plus(int4, int8) to get
used in any cross-datatype case that could coerce and didn't have a
stronger match (ie, one of the arguments exactly matching a plus argument
per b or c) so that's probably not good enough.
