Re: replace plugins directory with GUC - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: replace plugins directory with GUC
Date
Msg-id 515357F4.6000307@gmx.net
Whole thread Raw
In response to Re: replace plugins directory with GUC  (Peter Eisentraut <peter_e@gmx.net>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: allowing privileges on untrusted languages
Next
From: Heikki Linnakangas
Date:
Subject: Catching resource leaks during WAL replay