Robert Haas <robertmhaas@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
