On Sat, Sep 14, 2013 at 4:15 PM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > We can attack the problem in several ways: > > - have an initdb switch to tweak the library path per cluster,
I see no advantage to making this impossible to change after initdb time. > - have a superuser-only GUC to tweak the library path, I could live with a GUC. Like Andres, I think it should be PGC_POSTMASTER. > - consider on-disk extension as templates and move their module files > somewhere private in $PGDATA and load the code from there I think this will be horrid mess of security vulnerabilities and upgrade woes. Here's another idea. At initdb time, create an empty directory called called pg_you_can_load_stuff_from_here (pick a better name) inside $PGDATA. Allow it to be replaced with a symlink. This would be similar to what we do today with pg_xlog. In fact, you can imagine an equivalent of initdb -X that does something precisely analogous. This feels a bit more natural to me than a GUC. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
