On Wed, 23 Jan 2002, Tom Lane wrote:
> The only alternative semantics that seem defensible at all are to stop
> at the first namespace that contains any matching-by-name op or func,
> and do resolution using only the candidates available in that namespace.
> That strikes me as not a good idea; for example, a user who defines a
> "+" operator in his own schema for his own datatype would be quite
> unhappy to find it masking all the "+" operators in the system schema.
>
> I believe that this behavior would be fairly reasonable if our
> backward-compatibility feature consists of a "public" namespace
> that all users can write in. OTOH I think it would not play at all
> well if we use Fernando's idea of an "any" wildcard in the search
> path. (1) Imagine the case where we have some users who are using
> the backward-compatible behavior while others have set up private
> namespaces. If Joe SmartGuy creates a "+" operator in his private
> namespace, it'll be visible to people using the "any" wildcard and
> possibly cause resolution-ambiguity failures for them, even though
> Joe deliberately did what he should do to avoid that. (2) "any"
> creates the problem of resolving multiple functions with identical
> signatures in different namespaces, with no reasonable rule for
> making the choice.
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.