Re: Package support for Postgres

On Thu, 18 Oct 2001, Peter Eisentraut wrote:

> Bill Studenmund writes:
>
> > Honestly, I do not understand why "global variables" have been such a sore
> > point for you.
>
> My point is that the proposed "package support" introduces two features
> that are a) independent, and b) already exist, at least in design.
> Schemas are already planned as a namespace mechanism.  Global variables in
> PLs already exist in some PLs.  Others can add it if they like.  There
> aren't any other features introduced by "package support" that I can see
> or that you have explicitly pointed out.

Then my explanations didn't click. Please let me try again.

The main feature of package support is that it greatly facilitates
developing large, complicated db applications. Like ones which require
multiple full-time developers to develop. I think PostgreSQL has the
internals to run these apps, and it should provide a developement
environment to encourage them.

That's what packages are about.

I have never developed an application that large. But I have talked to our
DBAs who have worked with such things in Oracle, and a few who have worked
on (developed) such large applications. They all have agreed that
something akin to packages is needed to make it work.

The seperate namespaces (for function names and for variables) mean that
different programmers don't have to coordinate the names of functions. Or
that the names have to have some de-ambiguating prefix to make them
different. All that has to happen is that different packages have
different names. When you through in the idea of developers releasing
libraries (packages) on the net, the minimality of coordination is even
more important.

The fact (for PostgreSQL i.e. this implimentation)  that types and
operators aren't namespaced off means that they effectively leak into the
enclosing database (or schema when we have them) so that making and
supporting new types can be the aim/result of the package.

For comaprison with other languages, packages strike me as comparable to
libraries (in C) or modules (say in Perl or Python). Neither libraries nor
modules realy do anything that can't be achieved otherwise in the
language. Yet they are a prefered method of developing code, especially
reused code. When you're making a program/application, you don't need to
concern yourself with (many) details about the code; you use the module
and that's it. Likewise here, an application developer/integrator need
only load a module, and then all the routines in it are available. You
don't for instance have to worry if the routines have names which overlap
ones you were using, or ones used worse yet by another set of routines you
want to use.

I think Jean-Michael's comments were right. While I'm not sure if things
will be as overwhelming as he predicted, packages (even as implimented in
my patch) will help people develop code libraries for PostgreSQL. And that
will make PostgreSQL applications easier.

Also, as I've come to understand what schemas are and aren't, I've
realized that they can be readily leveraged to help with schema support.

Schemas, at least according to the SQL92 spec I have looked at (I'd love
to see a later spec), are namespaces only for tables and views (and
character sets and a number of other things which PostreSQL doesn't
support).  They don't touch on functions. Sure, PostgreSQL could decide to
do something with functions, but if we do, we're improvising, and I see no
reason to improvise differently than other DBMSs have done. There may be
one, but I don't see it.

Also, as I understand schemas (which could be wrong), there is a
difference in emphasis between schemas and packages. Schemas are a way to
partition your database, so that different parts of an application see
only a subsection of the whole database. You can have some parts only able
to access one or another schema, while other parts can access multiple
schemas. Packages however are designed to help you build the tools to make
the applications work (providing toolchests of code for instance). It's
like schemas are a more top-down design element, and packages are
bottom-up.

Where I see the interaction is that we want to have different schemas have
schema-specific functions, we just have a package implicitly assosciated
with each schema which contains the traditional functions and aggregates
(and types and operators) of that schema.

> So the two questions I ask myself are:
>
> 1. Are package namespaces "better" than schemas?  The answer to that is
> no, because schemas are more standard and more general.

See above; I never said packages were better than schemas (nor worse). I
said they were different parts of the puzzle. I think they are both
important and valuable.

> 2. Are global variables via packages "better" than the existing setups?
> My answer to that is again no, because the existing setups respect
> language conventions, maintain the separation of the backend and the
> language handlers, and of course they are already there and used.

All package variables are to the backend are entries in a table,
pg_packglobal, provided for the convenience of the language handler. If
the handler doesn't want to do anything with them, then it doesn't and
that's no loss.

> So as a consequence we have to ask ourselves,
>
> 3. Do "packages" add anything more to the table than those two elementary
> features?  Please educate us.

See above.

> 4. Would it make sense to provide "packages" alongside the existing
> mechanisms that accomplish approximately the same thing.  That could be
> debated, in case we agree that they are approximately the same thing.

I don't agree that they are approximatly the same thing, though I agree
that many of the things packages do can be cobbled together (more
painfully) without them.

Hopefully these explanations will come across clearer.

Take care,

Bill