Re: extension_control_path

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Why is that a good idea? It's certainly not going to simplify DBAs'
>> lives, more the reverse. ("This dump won't reload." "Uh, where did
>> you get that extension from?" "Ummm...")

> The latest users for the feature are the Red Hat team working on Open
> Shift where they want to have co-existing per-user PostgreSQL clusters
> on a machine, each with its own set of extensions.

Um ... "own set of installed extensions" doesn't need to mean "own set of
available extensions", any more than those clusters need to have their
own Postgres executables. If the clusters *do* have their own
executables, eg because they're different PG versions, then they can
certainly also have their own $SHAREDIR trees too. So this example
is totally without value for your case.

> Having extension_control_path also allows to install extension files in
> a place not owned by root.

As far as the control files go, there's nothing saying that
$SHAREDIR/extension has to be root-owned. If there are .so's involved,
I do not believe the Red Hat crew is asking you to support loading .so's
from non-root-owned dirs, because that'd be against their own corporate
security policies. (But in any case, where we find the control and SQL
files need not have anything to do with where the .so's are.)

> Lastly, as a developer, you might enjoy being able to have your own
> non-system-global place to install extensions, as Andres did explain on
> this list not too long ago.

And again, if you're working on a development version, $SHAREDIR/extension
is probably owned by you anyway.

I don't see that any of these scenarios create a need to install extension
files anywhere but $SHAREDIR/extension.

regards, tom lane