Re: extension_control_path - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: extension_control_path
Date
Msg-id 530D1430.3090402@gmx.net
Whole thread Raw
In response to Re: extension_control_path  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: extension_control_path  (Stephen Frost <sfrost@snowman.net>)
Re: extension_control_path  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List 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 by date:

Previous
From: Josh Berkus
Date:
Subject: Re: jsonb and nested hstore
Next
From: Merlin Moncure
Date:
Subject: Re: jsonb and nested hstore