Several weeks ago, I started a pgsql-hackers thread proposing a new extension file organization and a search path GUC for finding extensions. The discussion of Christoph Berg’s extension_destdir
patch inspired this proposal. These threads cover quite a lot of territory, so I want to pull together a more unified, public proposal.
Here goes.
Challenges
A number of challenges face extension users, thanks to extension file organization in the Postgres core. The common thread among them is the need to add extensions without changing the contents of the Postgres installation itself.
Packager Testing
On Debian systems, the user account that creates extension packages lacks permission to add files to Postgres install. But testing extensions requires installing the extension where Postgres can find it. Moreover, extensions ideally build against a clean Postgres install; adding an extension in order to run make installcheck
would pollute it.
Christoph’s patch solves these problems by adding a second lookup path for extensions and dynamic modules, so that Postgres can load them directly from the package build directory.
Alas, the patch isn’t ideal, because it simply specifies a prefix and appends the full pg_config
directory paths to it. For example, if --sharedir
outputs /opt/share
and extension_destdir
GUC is set to /tmp/build/myext
, the patch will search in /tmp/build/myext/opt/share
. This approach works for the packaging use case, which explicitly uses full paths with a prefix, but would be weird for other use cases.
Peter Eisentraut proposed an alternate patch with a new GUC
, extension_control_path
, that provides a more typical search path pattern to find extension control files, but doesn’t account for shared modules that ship with an extension, requiring that they still live in the dynamic_library_path
. Installing into custom directories requires the undocumented datadir
and p