Re: modules - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: modules
Date
Msg-id 87lk3tfi8u.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: modules  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> 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.
>
> That seems like a great way to persuade people that "safe" isn't
> so safe after all.  If I were the kind of ISP that doesn't want
> people to have database superuser, there's no way on earth that
> I'd accept a setting like that.

Huh? Nobody's forcing the sysadmin to *install* any modules. But if they do
they shouldn't have to overwrite files that came with their OS. All I'm saying
is that distribution packagers need two directories, one for files installed
as part of a distribution package and one for files the sysadmin wants to
install himself for his users.

That's exactly like, say, /usr/share/emacs/site-lisp and
/usr/local/share/emacs/site-lisp.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Garbage pad bytes within datums are bad news
Next
From: Gregory Stark
Date:
Subject: Re: Garbage pad bytes within datums are bad news