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

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: 23 January 2002 00:02
> To: Peter Eisentraut
> Cc: Fernando Nasser; pgsql-hackers@postgresql.org
> Subject: Re: RFD: schemas and different kinds of Postgres objects 
> 
> 
> 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
> 
Could you just have a general rule of search in order of age (by OID)? This
should prevent changes to existing operation when new definitions come along
(unless new definition is in new own schema or default).
Cheers,
- Stuart