Re: Where to load modules from? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Where to load modules from?
Date
Msg-id CA+TgmoYvYLteHKgH+fEP_NFeB0mQa08O7hDiMkh_gAbps0UzVw@mail.gmail.com
Whole thread Raw
In response to Re: Where to load modules from?  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Where to load modules from?
List pgsql-hackers
On Thu, Sep 19, 2013 at 5:54 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-09-19 22:56:52 +0200, Dimitri Fontaine wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>> >> I think I'd prefer a GUC that allows specifying multiple directories
>> >> that are searched in order to a single symlinked directory.
>> >
>> > Why?
>> >
>> > I ask because I have the opposite preference, based on the precedent
>> > of pg_xlog.
>
> Because I want to specify multiple paths. E.g. one with modules for a
> specific postgres version, one for the cluster and one for my
> development directory.
> Now we could recursively search a directory that contains symlinks to
> directories, but that seems ugly.

I see.  My main hesitation is around security.  I feel somehow that
changing a GUC to trojan the system would be easier for a remote user
to accomplish than having to replace a directory with a symlink.

>> In an effort to reach consensus, what about having both, with the GUC
>> being empty by default? That way you have a default per-cluster place
>> where to stuff binaries to be loaded, and a GUC to manage finer settings
>> if needs be.
>
> Well, we can have the guc have a default value of $datadir/pg_lib or
> such. But using two independent mechanisms seems like a bad idea to me.

Heartily agreed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Assertions in PL/PgSQL
Next
From: Andres Freund
Date:
Subject: Re: Where to load modules from?