Re: modules - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: modules
Date
Msg-id 87abk9h2q5.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: modules  (Aidan Van Dyk <aidan@highrise.ca>)
Responses Re: modules  (Aidan Van Dyk <aidan@highrise.ca>)
Re: modules  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: modules  ("Tom Dunstan" <pgsql@tomd.cc>)
Re: modules  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"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.

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.

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.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!
 


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: modules
Next
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: Implement current_query(), that shows the currently executing