大卫·惠勒：扩展打包的冒险
内容提要
在PGConf.dev上，我分享了开发PGXN Meta v2的经验，讨论了自动打包、依赖解决和CloudNativePG容器的扩展部署，提出了改进扩展搜索路径和依赖管理的建议，以简化安装过程并支持多操作系统。
关键要点
-
在PGConf.dev上分享了开发PGXN Meta v2的经验。
-
讨论了自动打包、依赖解决和CloudNativePG容器的扩展部署。
-
提出了改进扩展搜索路径和依赖管理的建议。
-
简化安装过程并支持多操作系统。
-
维护Trunk注册表，重构和升级200多个扩展，添加Postgres 17构建。
-
PGXN v2规范支持第三方依赖，允许扩展定义其依赖关系。
-
提出了支持多个操作系统和版本的PGXN二进制注册表的计划。
-
CloudNativePG容器的扩展部署方案，利用Postgres 18的extension_control_path GUC。
-
建议使用单一扩展搜索路径GUC，简化扩展的安装和管理。
-
提出了Trunk打包格式的依赖模式，支持所有操作系统。
-
项目状态接近完成，预计将发布PGXN v2构建SDK。
-
希望未来能完成Trunk格式和依赖模式的开发，提交扩展搜索路径补丁。
延伸问答
PGXN Meta v2的开发经验分享了哪些内容？
分享了自动打包、依赖解决和CloudNativePG容器的扩展部署经验。
如何简化扩展的安装过程？
通过改进扩展搜索路径和依赖管理，提出使用单一扩展搜索路径GUC来简化安装过程。
PGXN v2规范支持哪些新特性？
支持第三方依赖，允许扩展定义其依赖关系，并计划支持多个操作系统和版本的PGXN二进制注册表。
CloudNativePG容器的扩展部署方案是什么？
利用Postgres 18的extension_control_path GUC和Kubernetes的ImageVolume特性进行扩展部署。
在扩展打包中遇到的主要挑战是什么？
主要挑战包括自动打包的复杂性和依赖解决，尤其是在支持多个操作系统和版本时。
PGXN v2的项目状态如何？
项目接近完成，预计将发布PGXN v2构建SDK，并希望未来能完成Trunk格式和依赖模式的开发。
