冯若航：再次接手一个 PostgreSQL 扩展：昨天是 vchord，今天是 pg_mooncake
内容提要
作者在接管vchord后，又接手了Rust编写的PostgreSQL扩展pg_mooncake。其开发团队Mooncake Labs被Databricks收购，上游停更一年多，且父扩展pg_duckdb随DuckDB 2.0升级导致其失效。作者分三步处理：从互联网档案馆恢复文档与博客；将版本升至0.3，适配pg_duckdb 1.2和pgrx 0.19.3；保持低负担维护。新版本已发布至Pigsty扩展仓库，支持PG 14–18及16种操作系统。
延伸解读
上游被收购后的连锁反应
Mooncake Labs 被 Databricks 收购后，pg_mooncake 上游停更一年多。更关键的是，它依赖的父扩展 pg_duckdb 随 DuckDB 2.0 升级而更新，导致子扩展失效。这说明在扩展生态中，父项目变动会直接冲击下游，依赖方需关注上游维护状态。
三步维护法的可复用性
作者用三步处理 pg_mooncake：从互联网档案馆恢复文档与博客；将版本升至 0.3，适配 pg_duckdb 1.2 和 pgrx 0.19.3；保持低负担维护。这套流程与前一天处理 vchord 相同，表明对熟悉 PostgreSQL 扩展架构的维护者，接管同类项目可形成可复用的操作模式。
发行版维护者的兜底角色
作者强调，发行版维护者的职责是编译、打包和交付可用软件。即使上游团队离开，发行层也应吸收冲击，保持软件供应链完整。文中提到有 Pigsty 用户在生产环境使用 pg_mooncake，若新版本中扩展消失，对用户伤害很大，因此需要有人维持其可用性。
低负担维护的边界
作者对 pg_mooncake 的日常维护定位为低负担：无需持续高频改动，只需在 PostgreSQL 大版本发布或 pgrx、pg_duckdb 出新版时定期更新，并顺带合入用户反馈的合理修改。这提示读者，此类接管项目的可持续性依赖于维护者设定清晰、有限的维护节奏。
Q&A
pg_mooncake 为什么需要有人接手维护？
因为其开发团队 Mooncake Labs 被 Databricks 收购，上游仓库停更一年多；同时父扩展 pg_duckdb 随 DuckDB 2.0 升级发布新版本，导致 pg_mooncake 失效，必须同步更新才能继续使用。
作者接手 pg_mooncake 后做了哪几步工作？
分三步：1) 从互联网档案馆恢复文档和工程博客并重新发布；2) 将版本从 0.2 升至 0.3，适配 pg_duckdb 1.2 和 pgrx 0.19.3；3) 保持低负担维护，仅在 PostgreSQL 大版本更新或依赖发布新版本时定期更新。
pg_mooncake 新版本支持哪些 PostgreSQL 版本和操作系统？
新版本已发布至 Pigsty 扩展仓库，提供预编译包，支持 PostgreSQL 14 到 18，覆盖 16 种操作系统。
作者为什么愿意维护这些被上游放弃的扩展？
因为作者是 Pigsty 发行版的维护者，有用户在生产环境使用 pg_mooncake；发行版维护者的职责是编译、打包和交付可用的软件，即使上游团队离开，也应吸收冲击，保持软件供应链完整，避免用户升级时依赖消失。
pg_mooncake 和 pg_duckdb 是什么关系？
pg_mooncake 是构建在 pg_duckdb 之上的子扩展，与 pg_duckdb 紧密耦合。当父扩展 pg_duckdb 升级（如因 DuckDB 2.0 发布新版本）时，子扩展必须同步更新，否则会失效。
作者如何低负担地维护 pg_mooncake？
日常维护不需要频繁变动，只需在 PostgreSQL 发布新大版本，或 pgrx、pg_duckdb 发布新版本时进行周期性更新；如果用户遇到问题或提出合理功能请求，可顺带合入更改。
