On Sat, 13 Oct 2001, Tom Lane wrote:
> Bill Studenmund <wrstuden@netbsd.org> writes:
> > The other choice is to just give the function's name. The first place
> > Postgres will look is in the package context used for parsing. If it's not
> > there (and that context wasn't "standard"), then it will look in
> > "standard".
>
> Hmm. How does/will all of this interact with SQL-style schemas?
>
> The reason I'm concerned is that if we want to retain the present
> convention that the rowtype of a table has the same name as the table,
> I think we are going to have to make type names schema-local, just
> like table names will be. And if type names are local to schemas
> then so must be the functions that operate on those types, and therefore
> also operators (which are merely syntactic sugar for functions).
Ahhh... There's the operators == sugar comment.
I agree with you above; types and functions need to be schema-specific.
> This seems like it will overlap and possibly conflict with the decisions
> you've made for packages. It also seems possible that a package *is*
> a schema, if schemas are defined that way --- does a package bring
> anything more to the table?
I'm repeating myself a little. :-)
Packages aren't schemas. What they bring to the table is they facilitate
making stored procedures (functions). You can have twelve different
developers working on twenty different packages, with no fear of name
conflicts. The package names will have to be different, so there can be
functions with the same names in different pacakges.
This ability isn't that important in small development projects, but is
really important for big ones. Think about big db applications, like
Clarify. Any project with multiple procedure authors. Without something
like packages, you'd need to spend a lot of effort coordinating names &
such so that they didn't conflict. With packages, it's rather easy.
Also, I think PostgreSQL can challenge the commercial databases for these
applications. But to do so, changing over to PG will need to be easy.
Having packages there will greatly help.
> I'd like to see schemas implemented per the spec in 7.3, so we need to
> coordinate all this stuff.
For the most part, I think packages and schemas are orthogonal. I'm taking
a cue from Oracle here. Oracle considers packages to be a schema-specific
object.
Take care,
Bill
