Re: RFD: schemas and different kinds of Postgres objects - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: RFD: schemas and different kinds of Postgres objects |
Date | |
Msg-id | 29436.1011744140@sss.pgh.pa.us Whole thread Raw |
In response to | Re: RFD: schemas and different kinds of Postgres objects (Peter Eisentraut <peter_e@gmx.net>) |
List | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.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
pgsql-hackers by date: