Re: Package support for Postgres - Mailing list pgsql-hackers

Bill Studenmund writes:

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

Of course nobody is forcing you to put types into subschemas.  But the
user would have the freedom to spread things around as he sees fit.

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

Maybe read "fixed" as "enhanced".

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

Other PLs have shown that storing global data in a language-typical way
*is* possible.  I read your argumentation as "PL/pgSQL is not designed to
have global variables, so I'm going to implement 'packages' as a way to
make some anyway".  Either PL/pgSQL is not designed for it, then there
should not be any -- at all.  Or it can handle them after all, but then
it's the business of the language handler to deal with it.

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

What you're describing is the equivalent of declaring global variables in
C but inventing a whole new mechanism in the operating system for it
called "package" (which also happens to be a namespace mechanism as a
second job).  Now, there are ways to exchange data between separate
programs or modules in C, such as message queues or shared memory.  (If
you think about it, what PL/Python is doing with its global dictionary is
just the same as shared memory.)  This works fine, but it doesn't affect
PostgreSQL proper in any way.

So, do something with PL/pgSQL.  Implement a global dictionary, or shared
memory, or some other way to share data between functions.  Call it
"package" if you like.  (Java has packages which are somewhat like that.)

> My concern with that is that then we have to make sure to dump it in the
> same order you entered it.

pg_dump can do dependency ordering if you ask it nicely. ;-)  When we
implement schemas we'll have to make sure it works anyway.  Thinking about
pg_dump when designing backend features is usually not worthwhile.

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