Re: [HACKERS] idea for 'module' support

Mark Hollomon wrote:

>
>
> As I've been playing with the PL/Perl implementation, it has dawned on me a
> fairly simple, but nice feature could be added.
>
> I would like to add the following command:
>
> LOAD PACKAGE 'package-name';
>
> Like the current 'LOAD' it would treat 'package-name'
> as shared library. But it would also call an intialization function
> in the library (package_init maybe?).
>
> For instance, a user may type:
>
> LOAD PACKAGE 'plperl';
>
> This would not only load the shared library "plperl.so", but call
> the function "package_init" which could the use the SPI facilities
> to properly setup the system tables for the new language.
>
> New types could be packaged the same way.
>
> This would give a very modular way to add 'packages' of functionality.

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.

2. Most of such functionality requires PostgreSQL superuser
rights (like installing C language functions). Thus it is
useless for a regular user.

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.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #