On Fri, 19 Oct 2001, Tom Lane wrote:
> Yeah. I am wondering whether we couldn't support Oracle-style packages
> as a thin layer of syntactic sugar on top of schemas. I am concerned
> about the prospect that "foo.bar" might mean either "object bar in
> schema foo" or "object bar in package foo".
See my note to Gunnar for why I think packages should be inside of schemas
rather than renamed schemas. Types and expecially operators would be much
more useful to the enclosing schema that way (I think).
Yes, there is an ambiguity between schema foo and package foo. I can think
of a few ways to deal with this.
1) Do whatever Oracle does, assuming it's not grotesque. Yes, I've said
that a lot. But I think PostgreSQL can really take some applications away
from the commercial DBMSs, and Oracle is #1 in that market. So Oracle
represents Prior Art of least surprise. :-)
2) If there is both a schema named foo and a package named foo, then
foo.bar should always take foo to be the schema. If we let a package in
the local schema named foo be found before the schema foo, then we would
get different results in said schema and another one (which didn't have a
package named foo in it).
3) Don't let schemas and packages have the same name. I actually believe
this is what Oracle does, though I haven't checked. I _have_ checked that
packages and tables can't have the same name, and built that into the
packages patches. I think requiring schemas to have names different from
tables and packages is a good thing, and would reduce ambiguity.
As an aside the reason I suspect this is what Oracle does is that Oracle
has a system table which contains a list of named objects. Tables and
packages show up as entries in this table, and I'd expect schemas would
too.
Take care,
Bill