Before I set off to convert some of the PostgreSQL code that I share between projects from migrations into extensions proper, I somehow become convinced that it was feasible to set up the path where Postgres will look for extension
.control files per cluster. However, I am now afraid that, during my pre-takeoff checks, I might have confused
SHAREDIR (retrievable via
I was counting on (something like)
dynamic_library_path also working for extensions, because without a path that I can add custom locations to:
- it's a bit difficult to install extensions at all from a CI deployment, because it requires a more complicated permission setup; and
- and rolling out experimental extension changes on the same server becomes tricky to impossible if all my
postgresclusters/processes have to share the same
To recap what I do know so far (to keep people from just copying back the official docs to me):
dynamic_libray_pathcan contain a
$libdirentry, which refers to
pg_config --pkglibdir, but can also contain custom entries.
- However, the documentation mentions the
dynamic_libray_pathGUC only in the context of “dynamically loadable module[s]”.
CREATE EXTENSIONdoesn't allow one to specify a path, neither absolute nor relative.
CREATE EXTENSIONdocumentation plainly states that:
PostgreSQL will create the extension using details from the file
- Section 38.17.1 of the documentation mirrors this:
[The] control file for each extension […] must be placed in the installation's
- Within the extension
directorycan be set so that the extension's
.sqlfiles are retrieved from another location. (The default is the aforementioned
- I encountered a 2020 mailing list message by Craig Ringer: “RFC:
dynamic_library_path”, which also suggest to me that, at least at the time, no such custom path mechanism existed for extensions.
- Sadly, there do not appear to be any follow-ups to that message.
I wouldn't mind having to start
postgres with some custom environment variable similar to
$PGDATA even if this means that I have to bypass the OS's excellent default cluster configuration and
If it turns out that I really cannot control the extension file location per
postgres cluster, I will probably try to use something like
mergerfs to overlay the files from the deployed extension directories onto
"$(pg_config --sharedir)/extension" so that the package manager can continue to write system-wide extensions to the “lower”, original