Re: replace plugins directory with GUC

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: replace plugins directory with GUC
Дата
Msg-id 515357F4.6000307@gmx.net
обсуждение исходный текст
Ответ на Re: replace plugins directory with GUC  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
On 1/15/13 7:04 AM, Peter Eisentraut wrote:
>> It would seem to be much more in the spirit of things to simply list
>> > the
>> > allowed plugins in a GUC variable, like
>> > 
>> > some_clever_name_here = $libdir/this, $libdir/that 
> Here is a patch, with some_clever_name = user_loadable_libraries.
> 
> There are obviously some conflict/transition issues with using
> user_loadable_libraries vs the plugins directory.  I have tried to
> explain the mechanisms in the documentation, but there are other choices
> possible in some situations.

After thinking about this some more, this is not actually the mechanism
I need for my particular application.  What I actually needed was
something in between shared_preload_libraries and
local_preload_libraries, namely that it is loaded into backend processes
only (not postmaster), but only by superusers, and typically configured
in postgresql.conf.

I'll postpone actually implementing that to the next release.

I'm not aware of anything that actually uses the "plugins" mechanism
(seeing that the debugger no longer does), so I don't know if this
present change would actually be an improvement or not for those
applications.  So I'd be OK with withdrawing this patch for now.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: allowing privileges on untrusted languages
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Catching resource leaks during WAL replay