From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Bill Studenmund <wrstuden(at)netbsd(dot)org> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Package support for Postgres |
Date: | 2001-10-16 20:14:08 |
Message-ID: | Pine.LNX.4.30.0110162044040.627-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)gmx(dot)net http://funkturm.homeip.net/~peter
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2001-10-16 21:10:58 | Re: delayed mail? |
Previous Message | Peter Eisentraut | 2001-10-16 20:13:43 | Re: ecpg - GRANT bug |