Re: Package support for Postgres

Bill Studenmund <wrstuden@netbsd.org> writes:
> ... operators and types in
> packages are in the same name space as are types and operators not in
> packages.

> For functions and aggregates, things are a little more complicated. First
> off, there is a package called "standard" which contains all types,
> aggregates, operators, and functions which aren't in a specific package.
> This includes all of the standard Postgres routines, and anything created
> with CREATE FUNCTION, CREATE AGGREGATE, CREATE OPERATOR, and CREATE TYPE.

> Secondly, parsing is always done in terms of a specified package context.
> If we are parsing an equation in a routine inside of a package, then the
> package context is that package. If we are just typing along in psql, then
> the package context is "standard".

> When you specify a function or aggregate, you have two choices. One is to
> specify a package, and a function in that package, like
> "nametest.process" to specify the "process" function in the "nametest"
> package.

> 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).

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 also wonder how the fixed, single-level namespace search path you
describe interacts with the SQL rules for schema search.  (I don't
actually know what those rules are offhand; haven't yet read the schema
parts of the spec in any detail...)

Also, both operators and functions normally go through ambiguity
resolution based on the types of their inputs.  How does the existence
of a name search path affect this --- are candidates nearer the front
of the search path preferred?  Offhand I'm not sure if they should get
any preference or not.

I'd like to see schemas implemented per the spec in 7.3, so we need to
coordinate all this stuff.
        regards, tom lane