在我开始将我在项目之间共享的一些 PostgreSQL 代码从迁移转换为适当的扩展之前，我以某种方式确信设置 Postgres 将在每个集群.control中查找扩展文件的路径是可行的。但是，我现在担心，在我的起飞前检查期间，我可能会混淆( retrievable via )。dynamic_libray_pathSHAREDIRpg_config --sharedir
我指望（类似的东西）dynamic_library_path也为扩展工作，因为没有我可以添加自定义位置的路径：
- 从 CI 部署安装扩展有点困难，因为它需要更复杂的权限设置；和
- 如果我的所有
postgres集群/进程都必须共享相同的SHAREDIR.
回顾一下我到目前为止所知道的（防止人们只是将官方文档复制给我）：
dynamic_libray_path可以包含$libdir引用的条目，pg_config --pkglibdir但也可以包含自定义条目。- 然而，该文档仅在“动态可加载模块[s]”的上下文中提到了
dynamic_libray_pathGUC 。 - 与
CREATE FUNCTIONand不同LOAD，CREATE EXTENSION不允许指定路径，无论是绝对路径还是相对路径。 - 该
CREATE EXTENSION文档明确指出：PostgreSQL 将使用文件中的详细信息创建扩展
SHAREDIR/extension/extension_name.control。 - 文档的第 38.17.1 节反映了这一点：
每个扩展 [...] 的 [] 控制文件必须放在安装
SHAREDIR/extension目录中。 - 在扩展
.control文件中，directory可以进行设置，以便从另一个位置检索扩展.sql的文件。（默认是前面提到的。）SHAREDIR/extension - 我遇到了 Craig Ringer 的 2020 邮件列表消息：“RFC:
extension_search_pathto supplementdynamic_library_path”，这也向我暗示，至少在当时，扩展没有这样的自定义路径机制。- 可悲的是，该消息似乎没有任何后续行动。
我不介意必须从postgres一些类似于的自定义环境变量开始，$PGDATA即使这意味着我必须绕过操作系统出色的默认集群配置和systemd结构。
如果事实证明我真的无法控制每个postgres集群的扩展文件位置，我可能会尝试使用类似mergerfs的方法将已部署的扩展目录中的文件覆盖到上面"$(pg_config --sharedir)/extension"，以便包管理器可以继续将系统范围的扩展写入“降低”，原版SHAREDIR。
正如文档告诉您的那样，扩展控制文件必须位于 中
$(pg_config --sharedir)/extension，并且无法配置不同的位置。