Re: RFD: schemas and different kinds of Postgres objects

On Wed, 23 Jan 2002, Tom Lane wrote:

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > OK, I can accept that. But then I want to get back at my original point,
> > namely that all database objects (except users and groups) should be in
> > schemas. This is also cleaner, simpler, and more flexible. There is
> > clearly demand for schema-local functions. So I think that designing this
> > system from the premise that a schema-qualified operator call will look
> > strange is the wrong end to start at.
>
> Okay, a fair point --- or you could have used my own argument against
> me: there's nothing wrong with designing a general mechanism and then
> choosing not to expose all of the functionality. So let's assume that
> functions and operators live in namespaces, and that we have some kind
> of search path across multiple namespaces for use when an unqualified
> name is given.
>
> Now, how is that going to play with resolution of ambiguous calls?
>
> The most reasonable semantics I can think of are to collect all the
> potential matches (matching op/func name) across all the searchable
> namespaces, discarding only those that have exactly the same signature
> as one in a prior namespace. Thus, eg, plus(int4,int4) in an earlier
> namespace would hide plus(int4,int4) in a later namespace in the search
> path, but it wouldn't hide plus(int8,int8). After we've collected all
> the visible alternatives, do resolution based on argument types the same
> way as we do now.
>
> 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.

There is a third behavior which is almost the first one. And it's the one
I use for function matching in the package diffs I made oh so long ago.
:-)

You look in the first namespace for all candidates. If one matches, you
use it. If two or more match, you throw the error we throw now. If none
match, you move on to the next namespace and repeat the search there.

It's what the code does now. It's not that hard. It's just essentially
turning part of the function lookup into a for loop over the namespaces.
:-)

It's easier than gathering everything as you only gather one namespace's
worth of matches at once.

Take care,

Bill