Re: RFD: schemas and different kinds of Postgres objects

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