Re: RFD: schemas and different kinds of Postgres objects - Mailing list pgsql-hackers

Peter Eisentraut <peter_e@gmx.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.

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.

So I'm still of the opinion that an "any" wildcard is too risky a
solution for our backwards-compatibility problem.
        regards, tom lane