Re: RFD: schemas and different kinds of Postgres objects

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> No, it doesn't work the same as today, because in that implementation
>> both A and B can create the same tablename without complaint. It then
>> becomes very unclear which instance other people will get (unless your
>> "any" placeholder somehow implies a search order).

> The "search any schema" switch is only intended for use with legacy
> databases, where duplicate names don't occur anyway.

That's a mighty narrow view of the world. Do you think that people had
better convert to SQL schemas before they ever again create a table?
The fact is that ordinary non-schema-aware usage will certainly lead to
the above scenario.

> that the switch probably doesn't make a whole lot of sense. However, to
> get reproduceable behaviour anyway we can just define a search order, such
> as by schema name.

Or say that you get an "ambiguous reference" error if there is more than
one possible candidate in the "any" namespace. (Although that opens the
door for innocent creation of a table foo by one user to break other
people's formerly-working queries that reference some other foo.)
Bottom line for me is that this is an untried concept. I think the
concept of an "any" searchlist entry is risky enough that I don't much
want to hang the entire usability of the implementation on the
assumption that we won't find any fatal problems with "any".

However, the argument over whether SQL92's concept of ownership should
be taken as gospel is not really the argument I wanted to have in this
thread. Is it possible to go back to the original point concerning
whether there should be different namespace boundaries for different
types of objects? You aren't going to avoid those issues by saying that
namespace == ownership is good enough.

I'm particularly troubled by the idea of trying to apply this "any"
lookup concept to resolution of overloaded operators and functions.
Suppose I have a reference func(type1,type2) that I'm trying to resolve,
and I have an inexact match (one requiring coercion) in my own schema.
Do I look to the "any" schema to see if there are better matches?
If so, what happens if the "any" schema contains multiple possibilities
with identical signatures (presumably created by different users)? ISTM
this will positively guarantee a resolution failure, since there's no
way for the resolver to prefer one over another. Thus, by creating
a "func(foo,bar)" function --- quite legally --- JRandomLuser might
break other people's formerly working queries that use other functions
named func. Although it's possible for this to happen now, it'll be
a lot more surprising if JRandomLuser thinks that his functions live
in his own private schema namespace.

I'm thinking that the overloading concept is not going to play well
at all with multiple namespaces for functions or operators, and that
we'd be best off to say that there is only one namespace (per database)
for these things.

regards, tom lane