Re: extension_control_path
От | Stephen Frost |
---|---|
Тема | Re: extension_control_path |
Дата | |
Msg-id | 20140206153251.GD2921@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: extension_control_path (Greg Stark <stark@mit.edu>) |
Ответы |
Re: extension_control_path
|
Список | pgsql-hackers |
* Greg Stark (stark@mit.edu) wrote: > On Tue, Feb 4, 2014 at 6:07 PM, David E. Wheeler <david@justatheory.com> wrote: > > The install failed, of course, because extensions want to install in $PGROOT/share/extensions. > > Homebrew sounds kind of confused. Having a non-root user have access > to make global system changes sounds like privilege escalation > vulnerability by design. I've not played w/ Homebrew myself, but it's installing into /usr/local and presumably that includes installing things into /usr/local/bin, so the notion that installing something from Homebrew isn't already (and intended to be) making global system changes doesn't quite line up. The end-admin would have to modify the system-installed postgresql.conf anyway to enable this other directory. David wasn't suggesting that Homebrew *should* be able to do so, he was pointing out that it *can't*, which all makes sense imv. > However putting that aside, it is fairly standard for software to > provide two directories for extensions/modules/plugins/etc. One for > distribution-built software such as /usr/share/emacs/site-lisp/ and > another for sysadmin customizations such as > /usr/local/share/emacs/site-lisp. The same idea as /usr/share/perl and > /usr/local/share/perl or with Python or anything else. Agreed. Thanks, Stephen
В списке pgsql-hackers по дате отправления: