开源接盘侠又来了：昨天 vchord，今天吃月饼
内容提要
冯若航因pg_mooncake开发团队被Databricks收购、项目停滞，且DuckDB 2.0与pg_duckdb升级导致无法使用，遂接手维护：恢复文档、将版本升至0.3以兼容pg_duckdb 1.2并升级pgrx，计划低频按需维护。两个扩展已收录Pigsty仓库，支持PG 14至18及16个操作系统。
延伸解读
上游断供后，发行版如何兜底
pg_mooncake 原团队被 Databricks 收购后一年多无更新，官方文档站已跳转至收购方官网。冯若航从互联网档案馆恢复文档，并将版本升至 0.3 以兼容 pg_duckdb 1.2，同时升级 pgrx 至 0.19.3。这显示发行版在开源项目烂尾时，可通过打包、编译和分发维持软件供应链，避免用户因上游停更而无法使用。
强依赖关系下的连锁升级风险
pg_mooncake 构建在 pg_duckdb 之上，DuckDB 2.0.0 发布后父扩展升级，子扩展若不跟进适配便无法使用。这种强依赖意味着底层大版本更新会直接传导至上层扩展。冯若航的适配工作包括同步 pg_duckdb 1.2 和 pgrx 0.19.3，并计划在 PostgreSQL 19 发布后继续跟进，提示读者关注扩展与底层组件的版本匹配。
低频维护模式的实际含义
冯若航将 pg_mooncake 的维护定为低频、按需演进：平时不频繁改动，每年 PostgreSQL 大版本发布或 pgrx、pg_duckdb 更新时集中跟进，用户有合适需求再处理。这种模式适合依赖稳定、更新不频繁的扩展，但也意味着新功能响应不会很快。读者若依赖该扩展，需留意上游关键更新节奏，并理解维护者按需处理的边界。
已收录 Pigsty 仓库的可用范围
vchord 和 pg_mooncake 均已正式发版并收录进 Pigsty 扩展仓库，支持 PostgreSQL 14 至 18，覆盖 16 个操作系统，可通过下载安装包或系统包管理器一键安装。对于使用 Pigsty 的用户，这意味着升级到新版本时不会突然失去该扩展；但文章未提及非 Pigsty 环境下的获取方式，读者需自行确认安装渠道。
Q&A
pg_mooncake 为什么需要有人接手维护？
因为 pg_mooncake 背后的开发团队 Mooncake Labs 被 Databricks 收购，项目停滞一年多没有更新。同时，它依赖的父扩展 pg_duckdb 随着 DuckDB 2.0 发布而升级，子扩展如果不适配更新就无法使用，所以需要有人接手维护。
冯若航接手 pg_mooncake 后做了哪些具体工作？
他做了三件事：第一，从互联网档案馆找回丢失的官方文档和历史博客；第二，将 pg_mooncake 从 0.2 升级到 0.3，兼容 pg_duckdb 1.2，并将 pgrx 框架升级到 0.19.3；第三，计划低频维护，每年在 PostgreSQL 大版本或相关依赖更新时集中跟进，并按用户需求酌情开发。
pg_mooncake 和 pg_duckdb 是什么关系？
pg_mooncake 是构建在 pg_duckdb 之上的子扩展，强依赖 pg_duckdb。当父扩展 pg_duckdb 升级时，子扩展 pg_mooncake 必须跟着适配更新，否则就无法使用。
现在如何获取和使用更新后的 pg_mooncake 和 vchord？
这两个扩展都已正式发版，并收录进 Pigsty 扩展仓库，支持 PostgreSQL 14 到 18 版本，覆盖 16 个操作系统。用户可以直接下载安装包，或者用系统包管理器一键安装体验。
冯若航对开源项目被收购或烂尾持什么态度？
他认为上游创业公司被收购、转型甚至弃坑烂尾是开源生态的常态。作为发行版维护者，他的职责是打包、编译和分发，确保不管上游如何，发行版能稳稳接住用户，不让软件供应链断掉。
pg_mooncake 的维护频率和后续计划是怎样的？
维护频率较低，平时不需要频繁折腾，每年在 PostgreSQL 发布大版本，或者 pgrx、pg_duckdb 更新时集中跟进适配。用户如果有新需求可以提出，作者会根据合适程度酌情实现。
