Re: extension_control_path - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: extension_control_path
Date
Msg-id m21u0ah6rn.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Re: extension_control_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: extension_control_path  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Extending BASE_BACKUP in replication protocol: incremental backup and backup format
Next
From: James Bottomley
Date:
Subject: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance