2013/1/15 Peter Eisentraut <pete...@gmx.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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
