Re: extension_control_path

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: extension_control_path
Дата
Msg-id m21u0ah6rn.fsf@2ndQuadrant.fr
обсуждение исходный текст
Ответ на Re: extension_control_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: extension_control_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Extending BASE_BACKUP in replication protocol: incremental backup and backup format
Следующее
От: James Bottomley
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance