Re: replace plugins directory with GUC

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: replace plugins directory with GUC
Date: 2013-03-27 20:35:00
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-03-27 20:40:14 Catching resource leaks during WAL replay
Previous Message Peter Eisentraut 2013-03-27 20:27:43 Re: allowing privileges on untrusted languages