Re: Package support for Postgres

Bill Studenmund writes:

> I disagree. Views and tables are the purview of schemas, which as I
> mentioned to Tom, strike me as being different from packages.

Well, obviously schemas are a namespacing mechanism for tables and views.
And apparently the "packages" you propose are (among other things) a
namespacing mechanism for functions.  But the fact is that schemas already
provide a namespacing mechanism for functions.  (That's what SQL says and
that's how it's going to happen.)  Now perhaps you want to have a
namespacing mechanism *below* schemas.  But then I think this could be
done with nested schemas, since the sub-schemas would really be the same
concept as a top-level schema.  That would be a much more general
mechanism.

> Packages basically are modules which make life easier for functions
> (and types and aggregates and operators).

Obviously there is a large number of ideas that "make life easier".  But
I'm still missing a clear statement what exactly the design idea behind
these packages is.  So far I understood namespace and global variables for
PL/pgSQL.  For the namespace thing we've already got a different design.
For global variables, see below.

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

That has never stopped us from doing anything. ;-)

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

Oracle appears to have beaten us to define the meaning of quite a few
things, but that doesn't mean we have to accept them.  We don't
re-implement Oracle here.  And exactly because all Oracle has is
procedures and PL/SQL, whereas PostgreSQL has operators, types, and such,
and user-defined procedural languages, designs may need to be changed or
thrown out.  It wouldn't be the first time.

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

Then PL/pgSQL should be fixed.  But that doesn't need a such a large
concept as "packages".  It could be as easy as

DECLARE GLOBAL...
BEGIN...
END

> 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 language handler should have no problem creating persistent storage --
I don't see that as a problem.  If the language is misdesigned that it
cannot be done (which I doubt, but consider the theoretical case) then the
language should be replaced by something better, but please keep in mind
that it's a PL/pgSQL problem only.  Maybe if you're from an Oracle
background this separation is not quite as natural.

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

Right, that's why I suggested allowing the CREATE statements in any order
so you could order them yourself to have the function before the types or
whatever you want.

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

Externally perhaps not, but internally these things happen all the time.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter