Re: Package support for Postgres

On Tue, 16 Oct 2001, Peter Eisentraut wrote:

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

Yes, I want a namespace below schemas.

The difference between packages and schemas is that schemas encapsulate
everything. As Tom pointed out, that includes types (and I'd assume
operators too). Packages do not encapsulate types and operators. That's
what makes them different from a sub-schema (assuming a sub-schema is a
schema within a schema).

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

See above.

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

Why is PL/pgSQL broken?

It has a very clean design element; you enter a code block, you get a new
namespace. You can declare variables in that namespace if you want. When
you use a variable name, PL/pgSQL looks in the current namespace, then the
parent, and so on. You exit a code block, the namespace goes away. That's
how C works, for instance.

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

The problem is not creating persistent storage; the issue is that the
langyage was designed to not use it. What you're proposing could be done,
but would effectivly be shoving the change in with a hammer. Also, any
other PLs which are based on languages with strict namespaces will have
the same problem.

Look at C for instance. What you're describing is the equivalent to
letting a function or procedure in C declare global variables. That's not
now the language works, and no one seems to mind. :-)

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

My concern with that is that then we have to make sure to dump it in the
same order you entered it. Right now, in general, pg_dump dumps objects in
stages; all of the languages are dumped, then all of the types, then the
functions, and so on. Functions needed for types and languages get dumped
right before the type or language which needs it.

If we go with strict package order mattering, then pg_dump needs to be
able to recreate that order. That means that it has to look in pg_proc,
pg_operator, pg_type, and pg_aggreagate, sort things (in the package being
dumped) by oid, and dump things in order of increasing oid. Nothing else
in pg_dump works like that. I'd rather not start.

I have however come up with another way to make BEFORE TYPE FUNCTION go
away. I'll just scan the types in a package (I doubt there will be many),
get a set of candidate names, and scan the functions in the package for
them. If they are found, they get added before the types do. So then the
decision as to when a function should get added is implicit, rather than
explicit.

I'll see about adding this before I send in the patch (it is the only
thing left).

Take care,

Bill