Re: Where to load modules from?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Where to load modules from?
Дата
Msg-id CA+Tgmob2kpV3_SnGhAFFcZJoGBXroEr_PkLMUNfAL0XJmH7sYw@mail.gmail.com
обсуждение исходный текст
Ответ на Where to load modules from?  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: Where to load modules from?  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: Where to load modules from?  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Sat, Sep 14, 2013 at 4:15 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> We can attack the problem in several ways:
>
>   - have an initdb switch to tweak the library path per cluster,

I see no advantage to making this impossible to change after initdb time.

>   - have a superuser-only GUC to tweak the library path,

I could live with a GUC.  Like Andres, I think it should be PGC_POSTMASTER.

>   - consider on-disk extension as templates and move their module files
>     somewhere private in $PGDATA and load the code from there

I think this will be horrid mess of security vulnerabilities and upgrade woes.

Here's another idea.  At initdb time, create an empty directory called
called pg_you_can_load_stuff_from_here (pick a better name) inside
$PGDATA.  Allow it to be replaced with a symlink.  This would be
similar to what we do today with pg_xlog.  In fact, you can imagine an
equivalent of initdb -X that does something precisely analogous.  This
feels a bit more natural to me than a GUC.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Where to load modules from?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Typo fix in spgtextproc.c