Re: extension_control_path

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: extension_control_path
Дата
Msg-id 530D1430.3090402@gmx.net
обсуждение исходный текст
Ответ на Re: extension_control_path  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: extension_control_path
Re: extension_control_path
Список pgsql-hackers
I'm massively in favor of this feature.  (I had started writing it about
three times myself.)

The problem I see, however, is that most extensions, by recommendation,
set module_pathname = '$libdir/pgfoo', and so relocating the control
files will still end up pointing to a not relocated library file.

We would need to remove that and then ask users to keep their
dynamic_library_path in sync with extension_control_path.  That's error
prone, of course.

In order to address this properly, we need a new directory structure
that keeps library files and control files together, similar to how
Python, Ruby, etc. install things, and then just one path for everything.

Now a few technical problems.

When an extension is not found, I get the error message

ERROR:  could not open extension control file "(null)": Bad address

Something is broken there.

In the documentation, order extension_control_path after
dynamic_library_path.

Also, the documentation states that this controls the location of the
control file, but it of course controls the location of the script files
also.  That should be made clearer.  (It becomes clearer if we just have
one path for everything. ;-) )




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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: jsonb and nested hstore
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: jsonb and nested hstore