Re: modules - Mailing list pgsql-hackers

On Sat, Apr 5, 2008 at 12:22 AM, Gregory Stark <stark@enterprisedb.com> wrote:
> "Aidan Van Dyk" <aidan@highrise.ca> writes:
>
>  > What if you didn't need super-user privileges to load "C" functions, on
>  > the conditions that:
>  > 1) There is no / in the obj_file filename (or some other "sanitizing"
>  >    rules)
>  > 2) You're database owner
>
>  That's an interesting idea. It has the property that no super-user is required
>  to do any fiddling *inside* your database. That is, the ISP can just do CREATE
>  DATABASE and then leave you have at it without having to deal with installing
>  modules or granting any permissions inside your database.

Maybe it didn't come across, but it's exactly what I've been
suggesting in this thread, albeit a slightly different solution.

My idea was to have an installed "module", and rather than allowing
$database_owner to create C language functions based on what are
really implementation details for the given extension, just allow them
to say e.g. "install module postgis;" or equivalent - this would then
run either some init function or an appropriately named and placed
install script that would take care of everything. A module would be
expected to provide an uninstall script, too, to allow "uninstall
module foo" or whatever.

Under this scenario end users don't need access to the install
scripts, don't need to know the exact library name, and aren't given
the ability to e.g. create C language functions in ways that weren't
intended, like declaring one taking the wrong variable types or
something. The sysadmin can trust the module to do the right thing -
they don't have to trust the user.

As far as getting sysadmins to install contrib, this then becomes
really easy - just install them all by default and let database owners
install them into their own dbs as they wish.

>  It also opens the door to .deb packagers being able to put pgfoundry modules
>  in the same space. No other suggestion has offered any help to anything except
>  blessed contrib modules.

Well, I actually was approaching the problem from the point of view of
creating yum installable rpms - killing contrib was just a nice side
effect :)

>  I would suggest a guc for the "safe" place and I would suggest it be a list of
>  places. And I would suggest that for OS packagers they really want two
>  locations on that list, something like:
>   /usr/lib/postgresql/modules;/usr/local/lib/postgresql/modules
>  That way users can compile and install their own modules into /usr/local
>  without interfering with modules which come from OS packages.

+1.

Cheers

Tom