Tom Lane <> writes:

> Dimitri Fontaine <> writes:
>> Tom Lane <> 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.

They have several clusters as in `initdb` running standard packaged
binaries, each user having its own set of processes running with only
his privileges.

So when applying your idea (well, my understanding of it), they would be
happy with a $SHAREDIR per initdb.

>> 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.)

But you can have a single $SHAREDIR per set of executables, right?

Please read the following email to know what they asked for and how they
do operate OpenShift:

Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to