Re: replace plugins directory with GUC

2013/1/15 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> On Tue, 2012-10-09 at 20:45 -0400, Peter Eisentraut wrote:
>> About that plugins directory ($libdir/plugins) ... I don't think we
>> ever
>> really got that to work sensibly. I don't remember the original
>> design
>> discussion, but I have seen a number of explanations offered over the
>> years. It's not clear who decides what to put in there (plugin
>> author,
>> packager, DBA?), how to put it there (move it, copy it, symlink it? --
>> no support in pgxs), and based on what criteria.
>>
>> 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.
>
Do we still need to continue hardwired "$libdir/plugins/" ?
If user_loadable_libraries allows to specify directories, not only libraries
themselves, and its default value is "$libdir/plugins/", it seems to me
this enhancement can offer more flexibility without losing backward
compatibility.

On the other hand, I'd like to see your opinion about fine-grained
superuser capabilities for module loading, that we have discussed
in the thread of untrusted language privilege.
It might be a situation where a capability to load module make sense.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>