On Wed, 30 Jan 2002, Tom Lane wrote:
> [ just catching up on this thread after a couple days thinking about
> other things ]
>
> However, that doesn't bear very much on the general argument of the
> thread. The bottom line is that we've put a whole lot of sweat into
> developing rules for resolving ambiguous operator and function calls,
> and I don't think we're going to be willing to toss all that effort into
> the scrap heap. But making namespace search order the dominant factor
> in choosing a function/operator (as Bill seems to want) would certainly
> break all that carefully-crafted effort. If we put the system namespace
> at the front of the search list then users would be unable to override
> standard operators with schema-local substitutes; clearly that's no
> good. But if we put it at the back, then a schema-local user operator
> would dominate all system entries of the same operator name, even for
> quite different types, and thereby it would break the resolution
> behavior.
I've changed my mind. :-)
> So I'm still of the opinion that my original suggestion is the only
> workable one: collect candidates across all available namespaces,
> discarding only those that are exact matches to candidates in earlier
> namespaces, and then apply the existing resolution rules to the
> collection. AFAICS this need not be any slower than what we do now,
> if the catalog is set up so that we can collect candidates in one
> indexscan without regard to namespace. The case where there actually
> are any exact matches to discard should be uncommon, so we can deal with
> it later on in the resolution process.
Sounds like the thing to do, and it matches the spec. :-)
Oh, you can make a path with your namespace before the built-in one. It's
just that if you don't include the built-in one (IMPLIMENTATION_SCHEMA) in
a path, you're supposed to prepend it to the specified list.
Take care,
Bill
