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

On Wed, 17 Oct 2001, Peter Eisentraut wrote:

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

???

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

Do you really think that my employer paid me for three months to come up
with an 800k diff _just_ to add global variables to PL/pgSQL? While part
of it, global variables are only one part of the work. I would actually
say it is a minor one.

Honestly, I do not understand why "global variables" have been such a sore
point for you. PLs for which they don't make sense like this don't have to
do it, and Oracle, on whom our Pl/pgSQL was based, thinks that they make
perfect sense for the language we copied.

Also, remember that this is an implimentation of Oracle packages for
Postgres. One of our goals was to make it so that you can mechanically
transform an Oracle package into a Postgres one, and vis versa. This
implimentation does a good job of that. To make the change you suggest
would not.

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

The thing is what you're talking about is more than just dependency
ordering (which I taught pg_dump to do for packages). "doing things in the
order you list" to me means that things get dumped in the exact same
order. Say you added some functions and then some operators and then some
functions. If order matters, then the operators should get generated in
the dump before the functions, even though there's no dependency-reason to
do so.

Maybe I'm taking that a bit more literal than you mean, but how it comes
across to me is unnecessarily difficult. We cah achieve the same thing
other ways.

I did however take your point that BEFORE TYPE FUNCTION should go away;
the patch I sent in does not have it. In the patch, stanzas in the CREATE
PACKAGE command are gathered, and done in sequence according to kind.
First the global variables are defined, then the initialization routines,
then functions which are needed for types in the package, then types, then
functions (other than the ones already done), aggregates, and operators.

Take care,

Bill