From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: extension_control_path |
Date: | 2014-01-14 16:23:24 |
Message-ID: | m21u0ah6rn.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Having extension_control_path also allows to install extension files in
a place not owned by root.
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.
> Assuming that there is some need for loading extensions from nonstandard
> places, would it be better to just allow a filename specification in
> CREATE EXTENSION? (I don't know the answer, since the use-case isn't
> apparent to me in the first place, but it seems worth asking.)
In the extension_control_path idea, we still are adressing needs where
the people managing the OS and the database are distinct sets. The GUC
allows the system admins to setup PostgreSQL the way they want, then the
database guy doesn't need to know anything about that at CREATE
EXTENSION time.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-01-14 16:37:25 | Re: extension_control_path |
Previous Message | Magnus Hagander | 2014-01-14 16:19:59 | Re: Extending BASE_BACKUP in replication protocol: incremental backup and backup format |