Re: Package support for Postgres

On Sat, 13 Oct 2001, Tom Lane wrote:

> Bill Studenmund <wrstuden(at)netbsd(dot)org> writes:
> > 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?

Independent as I understand it. Schemas (as I understand Oracle schemas)
operate at a level above the level where packages operate.

> 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 don't think it conflicts. My understanding of schemas is rather
simplistic and practical. As I understand it, they correspond roughly to
databases in PG. So with schema support, one database can essentially
reach into another one. Package support deals with the functions (and
types and in this case aggregates and operators) that schema support would
find in the other schemas/databases.

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

Should be independent. The searching only happens when you are not in the
"standard" package, and you give just a function name for a function.
The searching would only happen in the current schems. If
you give a schema name, then I'd expect PG to look in that schema, in
standard, for that function. If you give both a schema and package name,
then PG would look in that package in that schema.

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

There is no name spacing for operators in my implimentation as to have one
strikes me as reducing the utility of having types and operators in a
package. For functions (and aggregates), I tried to touch on that in the
latter part of my message; that's what the example with
"process(changer(4))" was about. PG will try to type coerce a function in
the current package before it looks in standard. So yes, candidates nearer
the front are prefered.

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

Sounds good. I don't think it will be that hard, though. :-)

Take care,

Bill