Re: extension_control_path

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: extension_control_path
Дата
Msg-id 20140114163725.GX2686@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: extension_control_path  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: extension_control_path  (Tom Dunstan <pgsql@tomd.cc>)
Список pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> > Please find attached to this email a patch implementing a new GUC that
> > allows users to setup a list of path where PostgreSQL will search for
> > the extension control files at CREATE EXTENSION time.
>
> 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...")

We *already* have that problem.  I don't think this makes it
particularly worse- you still need to go back to the old box and look at
what came from where.  Sure, you *might* be lucky enough to find the
right extension by guessing at what packages were installed or searching
for one that looks like the correct one, but then, you might discover
that the version available isn't the right version for the database
you're trying to restore anyway.  Indeed, this might allow folks who
don't particularly care for package systems to build consistent dumps
without having to worry quite as much about what the package system is
doing.

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

For my 2c, I could absolutely see it as being worthwhile to have an
independent directory to install not-from-package extensions.  That
would keep things which are "managed by the package system" and things
which are installed independent separate, which is absolutely a good
thing, imv.
Thanks,
    Stephen

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

Предыдущее
От: Trond Myklebust
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: [PATCH] Negative Transition Aggregate Functions (WIP)