From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Where to load modules from? |
Date: | 2013-09-20 12:06:56 |
Message-ID: | CA+TgmoYvYLteHKgH+fEP_NFeB0mQa08O7hDiMkh_gAbps0UzVw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 19, 2013 at 5:54 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-09-19 22:56:52 +0200, Dimitri Fontaine wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-09-20 12:10:38 | Re: Where to load modules from? |
Previous Message | Robert Haas | 2013-09-20 11:59:30 | Re: Assertions in PL/PgSQL |