Robert Haas <robertmh...@gmail.com> writes: >> - 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.
I think it's a solution to that horrid mess. Care to expand on your thoughs? > 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. I like that too. Now the thing I've heard the most about our extension infrastructure is how to make it support loading different versions of the same module in different databases in the same cluster. The second one on that topic might be why are extensions managed per-database except for their binary module parts? For that reason I proposed have the same mechanism as what you say here, but with a per-database directory layout. Thinking about it more, I think we would actually need both: some extensions need shared_preload_libraries and cluster-wide settings is all we can offer here. For local_preload_libraries compatible ones, then per-database setting would be best. Maybe adding a system view listing all the currently loaded modules, which extension made the system load them (if any) and where it was loaded from, superuser only, would then be appropriate. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers