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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
