Jan Wieck wrote:
>
> 1. All the functionality required to install such a package
> is only needed once per database (or if thrown into
> template1 once per installation). But the entire shared
> object has to be linked into each time a backend needs
> one single function from it. I'm not sure if it's such a
> good idea to waste more and more address space for
> administrative stuff that isn't required at runtime.
*shrug*. I don't see this as very important, but then, I'm not trying
to run a server that is servicing 100's or 1000's of requests per
hour either. A valid point in the general case.
Hmmmm. Of course, nothing says that the package_init stuff has be in
the same file as the runtine stuff. But then what would be the
difference from a \i of a SQL script?
>
> 2. Most of such functionality requires PostgreSQL superuser
> rights (like installing C language functions). Thus it is
> useless for a regular user.
Well, no more useless than C language functions right now. I had
in the back of my mind that there would be an 'approved' module
location. If a module resides there, then loading would occur as
if done by the superuser. It would be the admin's responibility to
make sure that that location was secure.
Of course, depending on the way the security model in PostgreSQL is
implemented, this may not be possible. I haven't looked.
>
> 3. Some of the features might be customizable. Procedural
> languages for example can be installed as trusted ones or
> not. Trusted languages can be used by any regular user to
> CREATE FUNCTION, untrusted ones can't. Placing the
> installation procedure inside the module itself doesn't
> make things easier here.
Passing parameters couldn't be that hard :
LOAD PACKAGE 'package_name' [WITH [attr=value]+];
Thank you for the feedback. I think the concept is worth while.
But apparently a good bit of work is needed on the mechanics.
--
Mark Hollomon
mhh@nortelnetworks.com
