Re: Package support for Postgres

On Sat, 13 Oct 2001, Peter Eisentraut wrote:

> Bill Studenmund writes:
>
> > So what are packages? In Oracle, they are a feature which helps developers
> > make stored procedures and functions.
>
> I think you have restricted yourself too much to functions and procedures.
> A package could/should also be able to contain views, tables, and such.

I disagree. Views and tables are the purview of schemas, which as I
mentioned to Tom, strike me as being different from packages. Packages
basically are modules which make life easier for functions (and types and
aggregates and operators).

If we really want to make tables and views and triggers part of packages,
we can. My big concern is that it then makes pg_dump harder. I'll go into
that more below.

> > They provide a name space for functions local to the package,
>
> Namespacing is the task of schemas. I think of packages as a bunch of
> objects that can be addressed under a common name (think RPMs).

Regrettablely Oracle beat you to it with what "packages" are in terms of
Oracle, and I suspect also in the minds of many DBAs.

I also think that you and Tom have something different in mind about the
namespacing in packages. It is purely a convenience for the package
developer; whenever you want to use a function built into the database,
you _don't_ have to type "standard." everywhere. Think what a PITA it
would be to have to say "standard.abs(" instead of "abs(" in your
functions! I'm sorry if my explanation went abstract quickly & making that
unclear.

> But it seems like some of this work could be used to implement schema
> support.

I think the big boost this will have to schema support is that it shows
how to make a far-reaching change to PostgreSQL. :-) It's an internal
schema change and more, just as schema support will be.

> > session-specific package variables,
>
> I think this is assuming a little too much about how a PL might operate.
> Some PLs already support this in their own language-specific way, with or
> without packages. Thus, I don't think packages should touch this.
> Actually, I think you could easily set up session variables in the package
> initializer function.

I agree that some PLs might do things their own way and so package
variables won't be as useful. If these variables are not appropriate to a
PL, it can ignore them.

PL/pgSQL is a counter-example, though, showing that something needs to be
done. It is not set up to support global variables; each code block
generates its own namespace, and removes it on the way out. Thus I can
not see a clean way to add package global variables to say the
initialization routine - this routine's exit code would need to not
destroy the context. That strikes me as a mess.

> > The last component of a package are the functions usable for type
> > declarations. They are declared as:
> > BEFORE TYPE FUNCTION <standard package function declaration>
> >
> > They are useful as the normal functions in a package are declared after
> > the types are declared, so that they can use a type newly-defined in a
> > package.
>
> I think it would make much more sense to allow the creation of objects in
> the CREATE PACKAGE command in any order. PostgreSQL has not so far had a
> concept of "functions suitable for type declarations" and we shouldn't add
> one.

I think you misread me slightly. BEFORE TYPE FUNCTION functions are
"usable" for type declarations, not "suitable" for them. Also, I didn't
say one key clause, "in this package". The main difference is when in the
creation of the package the functions are created; they get created before
the types, rather than after.

This concept is new to PostgreSQL because PostgreSQL has never before
chained creations together like this.

Thinking about it though it would be feasable to scan the list of types in
the package, and see if there are references to functions declared in that
package, and if so to create them before the types get declared. That
would remove the need for BEFORE TYPE FUNCTION and also make pg_dump a
little simpler.

Take care,

Bill