504個擴展，PostgreSQL 的天花板在哪里？

一個 Issue ，引發擴展馬拉松；32 個新擴展告訴你，PostgreSQL 正在變成什么；504 個擴展，PostgreSQL 生態的天花板在哪？

從一個化學擴展說起

兩天前，一位用戶在 GitHub 上給我提了個 Issue：他在用 RDKit —— 化學信息學領域的事實標準庫，能在 PostgreSQL 里做分子結構存儲、子結構檢索和相似性計算。 但他發現 PGDG 官方打包的版本缺了 InChI 功能，他自己折騰了半天，加上編譯參數后總算跑通了，但還是希望 Pigsty 能原生支持。

但 RDKit 確實是個硬骨頭。大約兩年前我就試過一次，想把它收進 Pigsty 的擴展倉庫，從 Debian 移植到 EL。 結果依賴太多了：Boost、Eigen、RapidJSON、Cairo，外加 InChI、Avalon 等可選模塊， 每個都有自己的編譯開關和操作系統默認庫版本兼容問題。折騰了一會沒跑通，就先擱置了。

但這次不一樣。有 Coding Agent 了。

用 Codex / Claude Code 處理這類"構建系統考古"任務簡直是降維打擊 —— 以前需要反復試錯的東西，現在基本一兩輪對話然后等著就行了。 這次發布，把 PGDG 打包到 InChI 支持的問題也一并解決了，本質上就是編譯時多開一個標志位再帶上 InChI 源碼。一把過，用戶也很滿意。

說實話，看到這種反饋挺開心的。做開源最開心的就是這個時候。

趁熱打鐵

既然手熱了，我就順便把積壓已久的幾個"歷史疑難雜癥"也一起清了。

plv8：V8 引擎的 PostgreSQL 綁定，之前在 EL10 上死活編譯不過，這次打了好幾個補丁終于搞定了穩定構建。

duckdb_fdw：允許從 PG 內部讀寫外部 DuckDB 文件，但之前會和 DuckDB 官方的 pg_duckdb 擴展爭搶共享庫，我只能忍痛臨時隱藏。這次把 duckdb_fdw 掛成了 pg_duckdb 的子擴展，共享同一份 libduckdb，沖突問題優雅解決，倆擴展又能并存了。

然后我就想：既然工具鏈都熱好了，不如把 PostgreSQL 生態里剩下那些值得收錄但一直沒啃的擴展也一并搞進來吧。 于是就有了這次的大更新 —— 新增 32 個擴展，更新 22 個，Pigsty 擴展倉庫總數正式突破 500，達到 504 個。

擴展目錄: pigsty.cc/ext[2]

504

155

332

71

0

481

488

479

473

457

EL

499

150

332

71

5

472

482

474

468

452

Debian

489

107

311

71

15

466

474

464

458

442

這五百個擴展中，一部分是 PG 自帶的擴展（70個），PGDG 官方打包的擴展（150 個），剩下的 330 個都是老馮自己收錄，打包，維護構建的第三方擴展。 基本上，Pigsty 在這個賽道上已經做到了前無古人，后無來者了。

這是啥概念？一般 RDS PG 上也就是幾十個擴展。比如最近火爆的 Supabase 上，去掉 PG 自帶的的 35 個 Contrib 擴展，實際上也就提供了 30 個不到的第三方 PG 擴展。

新擴展

這批新增擴展的畫風相當硬核。按大類可以分四組：

數據域擴展：把化學分子、RDF 三元組、BSON、Protobuf、循環日程這些"復雜對象"變成數據庫一等公民；

查詢能力擴展：稀疏線代與圖算法、Datalog 圖查詢、全文檢索、混合排序融合、遞歸 SQL 模板引擎；

生產工程擴展： 深度可觀測性、查詢遙測導出、CDC 到 MQTT、COPY 命令攔截、DDL 邏輯復制補全、輕量分布式鎖、軟告警式數據質量管理；

開發者體驗擴展： 會話變量、偽自治事務日志、自然語言時間解析，以及壓軸的 —— 在數據庫里跑 TypeScript。

這些擴展共同指向一個趨勢：PostgreSQL 的擴展層正在把數據庫推向應用與數據平臺的中間地帶。很多原本需要獨立服務才能解決的問題，現在可以在一條 SQL 事務邊界內搞定。

這就是 PostgreSQL 極致可擴展性的魅力所在。

新擴展大觀園

這次新加入了 32 個新擴展，下面的部分是請 Claude/Codex/Gemini 三劍客進行研究匯總摘要，用于幫助讀者快速了解每個擴展的核心功能、技術實現和適用場景。

1. rdkit —— 把化學信息學搬進 PostgreSQL

RDKit 是開源化學信息學領域的事實標準庫，由 Greg Landrum 發起（最初在 Novartis，現屬 T5 Informatics），其 PostgreSQL cartridge 模塊將分子結構存儲、子結構檢索和相似性計算直接帶入關系數據庫。對于制藥公司和化學研究機構而言，這意味著可以用標準 SQL 查詢數百萬化合物，無需借助外部工具鏈。

RDKit cartridge 引入了兩組核心數據類型：mol（分子）和 qmol（查詢分子，即 SMARTS 模式），以及 bfp/sfp（位指紋/稀疏指紋）。操作符方面，@> 用于子結構匹配，% 用于 Tanimoto 相似性判斷，<%> 作為距離運算符。所有這些操作都可以通過 GiST 索引加速——索引內部基于指紋篩選進行快速預過濾，再做精確匹配。關鍵函數包括 mol_from_smiles()、morganbv_fp()（Morgan 指紋）、tanimoto_sml() 等，配合 rdkit.tanimoto_threshold 等 GUC 參數可以調節檢索靈敏度。

以 ChEMBL 數據庫（187 萬化合物）為例：

SELECT * FROM rdk.mols WHERE m @> 'c1[o,s]ncn1'::qmol LIMIT 500;

應用場景集中在藥物研發的幾個關鍵環節：先導化合物骨架搜索（在百萬級化合物庫中做子結構匹配）、SAR 分析（通過相似性檢索尋找活性類似物）、化合物注冊系統（利用結構指紋做重復性檢查）、以及商業化合物目錄檢索（如 eMolecules 的 600 萬+化合物數據集）。

工程落地時需要注意：cartridge 的重點不在"能不能算"，而在"能不能被索引、能不能被 planner 正確利用"。索引策略與查詢模板需要提前固定下來，否則很容易寫出正確但慢的結構過濾。在 187 萬化合物上子結構檢索耗時在 88ms 至 1900ms 之間，經過優化可以處理 600 萬+化合物規模的數據集。BSD 許可證，Docker 鏡像（如 mcs07/postgres-rdkit）和 conda 安裝均已就緒。

2. provsql —— 半環溯源讓查詢結果"可追溯"

ProvSQL 由巴黎高等師范學校教授 Pierre Senellart 和 INRIA Valda 團隊開發，發表于 VLDB 2018。它為 PostgreSQL 添加 (m-)半環溯源（semiring provenance） 和不確定性管理——能自動追蹤每個查詢結果是由哪些基礎元組"推導"出來的，并支持在不同代數結構（布爾、安全等級、計數、概率）下對溯源信息進行求值。

核心機制是通過 PostgreSQL hook 攔截查詢執行，為每個表自動添加一個隱藏的 provsql 列，存儲指向溯源電路（provenance circuit）的 UUID。支持的 SQL 子集相當廣泛：SELECT-FROM-WHERE、JOIN、GROUP BY、DISTINCT、UNION/EXCEPT、聚合、HAVING，甚至在 PG 14+ 上支持 INSERT/DELETE/UPDATE 的溯源追蹤。核心函數包括 add_provenance() 啟用追蹤、provenance_evaluate() 對溯源進行求值、formula() 輸出布爾公式、probability_evaluate() 計算概率。概率求值支持多種算法：從樸素求值到 Monte-Carlo 采樣，再到 d-DNNF 編譯（借助 d4、c2d 等外部求解器）。

SELECT city, probability_evaluate(provenance()) FROM result;

ProvSQL 適合四類場景：安全分級傳播——查詢結果自動繼承源數據中最高的安全等級；概率數據庫——當基礎數據帶有可信度評分時，計算查詢結果的正確概率；數據血緣審計——精確追蹤每個結果行來源于哪些源元組，并支持 PROV-XML 標準導出；可信度評估——例如在刑事調查場景中，通過溯源加權評估目擊者陳述的可靠性。

ProvSQL 的價值往往體現在"可組合性"：溯源結果不是字符串日志，而是可以繼續被函數處理的對象。建議用于關鍵鏈路（核心報表/模型特征/合規計算），而非全庫無差別開啟。C/C++ 實現（依賴 Boost 庫），溯源電路存儲在共享內存中。支持 PG 10–18，MIT 許可證。

3. onesparse —— 在 SQL 里跑十億邊級圖算法

OneSparse 將高性能稀疏線性代數帶入 PostgreSQL，封裝了 SuiteSparse:GraphBLAS 庫。開發者 Michel Pelletier 是 GraphBLAS C API 委員會成員，顧問團隊包括 SuiteSparse 作者 Timothy A. Davis 教授（SIAM/ACM/IEEE Fellow）。核心理念是將圖表示為稀疏矩陣，用矩陣乘法實現 BFS、PageRank、三角中心性等圖算法——而這一切都在 SQL 中完成。

擴展引入了 matrix（稀疏矩陣）、vector（稀疏向量）、scalar、semiring、monoid 等數據類型，以及 @（矩陣乘法/plus_times 半環）等操作符。圖算法方面內置了 BFS（層級和父節點兩種模式）、PageRank、三角中心性、度中心性、單源最短路徑等，均來自 LAGraph 庫。技術上，它將 GraphBLAS 的不透明句柄封裝在 PostgreSQL 的 Expanded Object Header 結構中，小圖（<1GB）使用 TOAST 存儲，大圖支持 Large Object 或文件系統。內置 JIT 編譯器支持 NVIDIA CUDA GPU 加速。

SELECT pagerank(graph) FROM karate;

在 GAP benchmark 上，對 43 億邊的圖執行 BFS 時達到了 每秒 70 億+邊的吞吐量（48 核 AMD EPYC 服務器）。應用場景包括金融反欺詐（交易網絡環檢測）、社交網絡分析、Graph RAG 等。不過，這類擴展是否"真好用"，取決于數據裝載/序列化格式是否與現有管道匹配，以及算子能否與 SQL Planner/并行執行相處融洽——建議先用小規模樣例把端到端鏈路跑通。

OneSparse 要求 PG 18 Beta 或更新版本，當前處于 Alpha 階段。Apache 2.0 許可證。

4. pg_datasentinel —— 容器時代的 PostgreSQL 深度可觀測性

pg_datasentinel 由 Datasentinel 公司的 Christophe Reveillère 開發，于 2026 年 4 月 10 日發布 1.0 版本。它為 PostgreSQL 添加了四大可觀測性能力，填補了原生監控視圖在容器化環境和運維預警方面的空白。

第一，擴展活動監控：在 pg_stat_activity 基礎上增加每個后端進程的內存使用量、實時臨時文件字節數，以及在 PG 18+ 上顯示當前執行計劃 ID。第二，容器資源可見性：報告 CPU 配額、內存限制、當前內存使用和 CPU 壓力，適用于 Docker、Kubernetes、OpenShift 或任何 cgroup 管理的環境。第三，事務回卷風險預估：追蹤 XID 和 MXID 消耗速率，提供到 aggressive-vacuum 和回卷限制的實時 ETA。第四，日志捕獲視圖：將 vacuum、analyze、臨時文件、checkpoint 事件記錄到共享內存環形緩沖區，解析為結構化計數和計時信息，支持實時 SQL 查詢。

FROM pg_datasentinel_wraparound;

對于在 Kubernetes 上運行 PostgreSQL 的團隊，pg_datasentinel 提供了無需外部監控代理即可獲得的容器級資源可見性。XID 回卷預警功能對運維尤為關鍵——眾所周知，XID 回卷會導致數據庫強制關閉，而 pg_datasentinel 通過追蹤消耗速率提供預測性告警，將"救火"變為"防火"。3-Clause BSD 許可證，要求 PG 15+。

5. datasketches —— Apache 出品的億級近似分析利器

Apache DataSketches 是 Apache 基金會項目（源自 Yahoo/Verizon Media），其 PostgreSQL 擴展將多種近似分析數據結構（Sketch）引入 SQL 世界。核心問題很明確：在海量數據上做精確的 COUNT(DISTINCT)、分位數計算和頻繁項統計太慢或太耗內存。

擴展提供七種 Sketch 類型：cpc_sketch（Compressed Probabilistic Counting）、hll_sketch（HyperLogLog）、theta_sketch（支持集合交并差運算的去重計數）、aod_sketch（Tuple sketch）、kll_float_sketch/kll_double_sketch（分位數估算）、req_float_sketch（尾部高精度分位數）、frequent_strings_sketch（頻繁項）。每種 Sketch 都提供 *_sketch_build()、*_sketch_union()、*_sketch_get_estimate() 等標準接口。

關鍵點不是"有個函數返回估計值"，而是 Sketch 作為可序列化對象可以被聚合合并，因此特別適合數據立方體式的近似指標：按維度切片預聚合 Sketch，查詢時按任意維度組合做 union 即可得到去重數。Sketch 在內存中是亞線性的，且可跨語言（Java、C++、Python、Rust、Go）做二進制兼容序列化。

) bar GROUP BY flavor;

典型應用：實時 UV 統計——不存儲用戶 ID 即可跨時間窗口合并去重；分布分析——在數十億事件上計算 p50/p95/p99 延遲而無需排序；受眾重疊分析——用 Theta Sketch 的交集運算計算"看過廣告 A 且訪問過網站 B"的用戶數。在 1 億行數據上，CPC Sketch 的去重計數約 20 秒完成（精確 COUNT(DISTINCT) 約 2 分鐘），相對誤差在個位數百分比范圍內。

6. pghydro —— 巴西國家水務局的排水網絡分析引擎

PgHydro 由巴西國家水務衛生局（ANA）的 GIS 專家 Alexandre de Amorim Teixeira 開發，構建在 PostGIS 之上，被 ANA 作為水資源管理的官方工具在全國范圍內使用，也在 FOSS4G 2022 上做過展示。

核心能力圍繞水文網絡的完整工作流展開：從原始 GIS 數據的導入和一致性校驗，到流向計算、Otto Pfafstetter 流域編碼（一種國際通用的分層流域分類系統）、上下游分析、匯水面積計算、Strahler 河流分級等。架構上采用模塊化設計，包含五個子擴展：pghydro（核心）、pgh_raster（DEM 柵格分析）、pgh_hgm（水文地貌特征）、pgh_consistency（拓撲一致性校驗）和 pgh_output（數據導出）。

SELECT pghydro.pghfn_calculatestrahlernumber();

適用于國家級水文數據庫管理、流域規劃與編碼、上下游污染影響分析（如確定某污染源上游的所有河段）、以及排水網絡拓撲一致性驗證。它更像一套專業領域的數據庫內 ETL/分析流水線——數據在 PostGIS 中管理，分析過程可在 SQL 里自動化，當原始地形/河網數據更新時，按函數流水線重算比手動腳本更可靠。配合 QGIS 的 PgHydroTools 插件可實現可視化操作。完全用 PL/pgSQL 編寫，GPLv2 許可證。

7. pg_stat_ch —— ClickHouse 官方出品的 PostgreSQL 查詢遙測

pg_stat_ch 由 ClickHouse 公司開發并開源（2025 年 2 月，"Postgres Week at ClickHouse"活動），作者是 Kaushik Iska。與 pg_stat_statements 在 PostgreSQL 內部做聚合統計不同，pg_stat_ch 將每條查詢的原始執行事件（包含 45 個字段、固定 4.6KB）實時流式導出到 ClickHouse，讓所有聚合分析（p50/p95/p99、Top 查詢、錯誤分析）在 ClickHouse 的分析引擎中完成。

數據管道架構為：PostgreSQL Hooks（前臺）→ 共享內存環形緩沖區 → 后臺 Worker → ClickHouse。45 個遙測字段覆蓋查詢計時、行數、緩沖區使用、WAL 使用、CPU 時間、JIT 指標（PG15+）、并行 Worker 統計（PG18+）、客戶端上下文（應用名、IP）、錯誤捕獲（SQLSTATE 碼）等。擴展使用 ClickHouse 原生二進制協議加 LZ4 壓縮，靜態鏈接 clickhouse-cpp 庫。為避免對 PostgreSQL 造成背壓，隊列溢出時丟棄事件（計數器記錄丟棄數）而非減慢數據庫——與 StatsD 的設計哲學一致。

GROUP BY query_id ORDER BY p99_ms DESC LIMIT 10;

ClickHouse 側預置了四個物化視圖：events_recent_1h（滾動 1 小時副本）、query_stats_5m（5 分鐘桶 + TDigest 分位數）、db_app_user_1m（按數據庫/應用/用戶的負載歸因）、errors_recent（7 天滾動錯誤窗口）。

性能令人印象深刻：p99 開銷約 5μs/條，在 pgbench 32 客戶端 36.6K TPS 下，30 秒內捕獲 770 萬事件且零丟棄，對 TPS 影響 <1%（36,658 vs 36,913 基線）。三層鎖爭用最小化策略：原子溢出檢查 → 非阻塞 LWLock 嘗試 → 每后端本地緩沖區（每事務刷新，減少約 5 倍鎖獲取次數）。把 PostgreSQL 做成"事務系統"，ClickHouse 做成"遙測倉庫"，職責分離，比從日志文件逆向解析穩定得多。支持 PG 16–18，Apache 2.0 許可證。

8. pg_rrf —— 一個函數搞定混合檢索的排序融合

pg_rrf 由日本開發者 yuiseki 開發（2026 年 1 月發布），用 Rust（pgrx）實現。它將 Reciprocal Rank Fusion（RRF） 封裝為原生 PostgreSQL 函數，解決混合檢索場景中"分數不可比"的工程痛點：不同檢索器輸出尺度不同，直接加權不好調，而 RRF 只依賴 rank。公式為 score(d) = Σ 1/(k + rank_i(d))，k 默認 60（Cormack et al., SIGIR 2009）。

擴展提供四個函數：rrf(rank_a, rank_b, k) 計算兩路融合分數、rrf3() 三路融合、rrfn(ranks[], k) N 路融合、以及最實用的 rrf_fuse(ids_a bigint[], ids_b bigint[], k)——接收兩個排序后的 ID 數組，返回融合后的 (id, score) 表。NULL 安全：只在一路出現的 ID 僅使用該路的排名計算得分。

ORDER BY fused.score DESC LIMIT 20;

這將原本需要 FULL OUTER JOIN + COALESCE 鏈 + 手動評分公式的 20+ 行 CTE 壓縮為一個函數調用。應用場景覆蓋 RAG 混合檢索（語義搜索 + 全文搜索融合）、電商產品搜索、多信號文檔排序等。把融合邏輯移到數據庫側，尤其當結果要繼續 JOIN 業務表時，減少了應用層拼接與排序的開銷。當前 v0.0.3，MIT 許可證。

9. pg_kazsearch —— 哈薩克語全文檢索的"從無到有"

pg_kazsearch 是首個 PostgreSQL 哈薩克語全文檢索擴展。哈薩克語是高度黏著語（agglutinative），一個詞如 мектептер?м?зде 承載了復數、領屬、位格等多層后綴，必須全部剝離才能到達詞根 мектеп。現有的 PostgreSQL 或 Elasticsearch 分析器都無法處理這一點。

擴展用 Rust（pgrx）實現，提供 kazakh_cfg 文本搜索配置和 pg_kazsearch_dict 詞典。詞干提取算法采用 BFS 后綴剝離，配合元音和諧驗證和基于 Apertium-kaz 的 21,863 個詞性標注詞根詞典防止過度詞干化。運行時可通過 ALTER TEXT SEARCH DICTIONARY 調整權重參數。

LIMIT 10;

在 2,999 篇文章上的基準測試顯示：查詢延遲 0.5ms（比 pg_trgm 快 2.8 倍），nDCG@10 提升 25%，Recall@10 提升 23%。適用于哈薩克語新聞/政府文檔檢索、電商搜索等場景——在多語種系統里把"低資源語言"檢索能力補齊，避免回退到粗糙的 trigram 模糊匹配。

10. pg_liquid —— Datalog 風格的圖查詢

pg_liquid 由 Michael Golfi（西雅圖）開發，把 Liquid/Datalog 風格的聲明式圖查詢帶進 PostgreSQL。你可以用 liquid.query(...) 在一次調用里聲明事實、定義規則并執行終止查詢，不必單獨搭圖數據庫。規則是 query-local（只在一次 liquid.query 中有效），支持事實斷言、遞歸傳遞閉包、復合查詢（compounds）和行規范化器。

ORDER BY 1;

它還支持把本體謂詞定義（如 DefPred）與 compound（如 OntologyClaim@(...)）結合，用 compound 攜帶溯源/置信信息，靠規則做 subclass closure 等推理。適合知識圖譜查詢、層級數據遍歷（組織架構、分類樹）、基于規則的業務邏輯系統等場景——當你不想引入獨立圖引擎時，用擴展把最關鍵的遞歸查詢補上。完全用 PL/pgSQL 實現，無外部依賴，項目處于早期階段。

11. logical_ddl —— 讓邏輯復制也能同步 DDL

PostgreSQL 的邏輯復制只處理 DML（INSERT/UPDATE/DELETE），不處理 DDL（ALTER TABLE 等），這是運維中的一大痛點——表結構不同步會直接中斷復制。logical_ddl 由 Samed Yildirim 開發，通過事件觸發器攔截 DDL 命令，將其反解析并保存到可被邏輯復制傳播的表中，訂閱端接收后生成等效 SQL 并執行。

支持的 DDL 操作包括：ALTER TABLE RENAME TO/RENAME COLUMN/ADD COLUMN/ALTER COLUMN TYPE/DROP COLUMN。數據類型兼容性方面：內建類型、數組、復合/域/枚舉類型可用，但這些類型的"定義復制"（如 CREATE TYPE）不在覆蓋范圍內。可通過 logical_ddl.publish_tablelist 按表和命令類型精細控制捕獲范圍。

VALUES ('my_table'::regclass, ARRAY['ADD COLUMN', 'DROP COLUMN']);

適用于邏輯復制環境的自動化 DDL 同步、零停機遷移、多數據中心 PostgreSQL 架構等。把"DDL 同步"從流程管理變成可審計的數據流，降低復制事故概率。MIT 許可證，PGXN 可用。約束、索引、默認值等尚未實現。

12. rdf_fdw —— 用 SQL 查詢語義網

rdf_fdw 由 Jim Jones 開發，是一個通過 SPARQL 端點訪問 RDF 三元組存儲的 Foreign Data Wrapper，架起關系型 SQL 世界與語義網/關聯數據世界之間的橋梁。它引入 rdfnode 數據類型處理 RDF 術語（IRI、語言標簽、數據類型），支持 WHERE/LIMIT/ORDER BY/DISTINCT 等條件的 SQL-to-SPARQL 下推，以及通過 SPARQL UPDATE 端點執行 INSERT/UPDATE/DELETE。

SELECT * FROM dbpedia_query WHERE o = 'some_value' LIMIT 10;

rdf_fdw_clone_table() 存儲過程支持將外部表數據分批克隆到本地表。需要注意的是，實現層面會把拉取到的數據加載到內存再轉換，面對大體量數據要謹慎評估內存與下推效果。適合關聯數據集成（DBpedia、Wikidata）、用 SQL/BI 工具鏈直接消費 SPARQL 端點等場景。MIT 許可證，支持 PG 9.5–18。

13. pgbson —— 比 JSONB 更精確的二進制文檔類型

pgbson（postgresbson）由 buzzm 開發，為 PostgreSQL 引入原生 BSON（Binary JSON）數據類型。BSON 相比 JSON 提供了一等公民的 datetime、decimal128、int32/int64、binary 等類型，解決了 JSON 在分布式系統數據交換中的精度丟失和類型模糊問題，保證二進制完美往返（BSON in = BSON out）。

核心 API 是兩類訪問方式：一類是高性能的 dotpath 函數——bson_get_string(bson, 'd.recordId')、bson_get_datetime()、bson_get_decimal128() 等，直接在底層結構上行走，只在終點分配內存；另一類是類似 JSON 的 -> / ->> 鏈式操作符，但每一步都要構造中間子結構，深層路徑會放大成本。兩者配合 B-Tree 和 HASH 索引，函數索引可實現 10,000 倍的查詢加速（相對于順序掃描）。輸入端支持 EJSON 格式。

SELECT (data->'d'->'amt'->>'$numberDecimal')::numeric FROM data_collection;

典型場景包括跨語言事件/文檔管道（Java → Kafka → Python → PostgreSQL）的精確類型保持、金融數據（decimal128 精確到分）、數字簽名（BSON 的確定性二進制格式支持可靠哈希）等。MIT 許可證，支持 PG 14–18。

14. pg_when —— 用自然語言描述時間

pg_when 由 frectonz 開發，把自然語言時間表達解析成 PostgreSQL 的 timestamptz 或 epoch。核心函數 when_is(text) 返回標準 timestamp，語法由三部分組成：日期 + at + 時間 + in + 時區。未指定時區時默認 UTC。

SELECT when_is('December 31, 2026 at evening');

另有 seconds_at()、millis_at()、micros_at()、nanos_at() 返回 UNIX 時間戳的不同精度。這不是調度器，而是解析器。適用于面向運營/客服的"人類時間輸入"落庫、數據修復/回填腳本中用自然語言代替拼日期函數、以及統一時區處理等場景。MIT 許可證。

15. pgmqtt —— 數據庫變更直推 MQTT

pgmqtt 由 RayElg 開發（Rust 實現），把 PostgreSQL 的變更（INSERT/UPDATE/DELETE）通過 CDC 直接變成 MQTT 消息推給訂閱者，同時也支持 MQTT 入站消息按映射寫回表。它不是通用 MQTT 客戶端，而是把"變更流"與"消息 broker"嵌到數據庫側，用 SQL 配置 topic 映射與 payload 模板。

);

IoT 場景尤其合適——無需外部中間件即可將數據庫狀態變化推送到邊緣設備，或將傳感器數據通過 MQTT 協議直接寫入表。也適用于事件驅動架構中的輕量消息分發，減少應用層的 glue code。Elastic License 2.0。

16. pg_query_rewrite —— 透明地偷梁換柱

pg_query_rewrite 由 Pierre Forstmann 開發，利用 ProcessUtility hook 實現 SQL 語句的運行時透明替換。規則基于精確字符串匹配（大小寫和空格敏感）存儲在共享內存中。

SELECT pgqr_rules();

這是一個"很鋒利"的工具：不支持帶參數的語句、最大長度約 32KB、匹配對大小寫/空格/分號敏感、規則不持久化（重啟丟失，需借助啟動 SQL 機制恢復）。適用于數據庫遷移期間對歷史系統發出的固定 SQL 做透明重定向、危險查詢臨時攔截、查詢 A/B 測試等。默認最多 10 條規則，支持 PG 9.5–18。

17. pgclone —— 一鍵克隆數據庫對象

pgclone 由 valehdba 開發（PGXN 上發布 2.0.0 版），定位非常直給：不用 pg_dump/pg_restore、不用 shell 腳本，直接從 SQL 調用函數把表、schema、數據庫、函數（甚至角色與權限）從源實例克隆到目標環境。

它使用 COPY 協議進行快速數據傳輸，支持異步操作與進度跟蹤，支持選擇性克隆（列/行過濾），DDL 也在覆蓋范圍內（索引、約束、觸發器、視圖、物化視圖、序列等），還提供數據脫敏與敏感列自動發現能力。

);

適用于開發/測試環境快速搭建（含 DDL、索引）、生產到預發的"帶脫敏克隆"、多庫遷移與驗證等。相比 pg_dump/pg_restore，它完全在數據庫內部完成，簡化了 DevOps 流程。

18. pgproto —— 原生 Protobuf 支持

pgproto 由 Apaezmx 開發，為 PostgreSQL 提供原生 Protocol Buffers（proto3）存儲、查詢、修改和索引支持。核心機制是"運行時 Schema 注冊 + 二進制遍歷"：把 FileDescriptorSet 注冊到 pb_schemas 后，protobuf 類型的列就能通過路徑數組提取嵌套字段。引入 -> 字段導航、#> 嵌套路徑訪問、|| 消息合并等操作符，以及 pb_set()/pb_insert()/pb_delete()/pb_to_json() 等函數。

CREATE INDEX idx_pb ON items ((data #> '{Outer, inner, id}'::text[]));

在 10 萬行基準測試中，pgproto 存儲僅 16 MB（JSONB 46 MB，原生關系 25 MB），全文檔檢索 5.9ms（關系模型 33.1ms 需多表 JOIN）。想保留 Protobuf 生態（RPC/消息）又希望數據庫側可索引可過濾時，這是一個有吸引力的選擇。適合 IoT 數據存儲、微服務事件倉庫、gRPC 數據層等。PostgreSQL License。

19. pg_fsql —— JSONB 驅動的遞歸 SQL 模板引擎

pg_fsql 由 yurc 開發，把"SQL 模板渲染 + 安全參數化執行 + 模板樹遞歸組合"做成擴展。模板按 dot-path 組成樹，子模板產出片段或 JSON，再注入父模板。支持占位符語法（{d[key]} 及不同轉義 !r/!j/!i）、SPI plan cache（按模板可選緩存）、多種命令類型（exec/ref/if/exec_tpl/map/NULL），以及 fsql.run 執行、fsql.render dry-run、fsql.tree、fsql.explain 等公共 API。不需要 superuser。

SELECT fsql.render('user_count', '{"status":"active"}');

這不是函數式 SQL，而是層次化模板引擎：目標是讓你用 JSON 請求體驅動 SQL 生成，減少應用層代碼分支。適用于動態報表生成、ETL 管道編排、多租戶查詢生成、以及把差異化 SQL 固化在模板表中配合權限管理等場景。

20. pg_dispatch —— 基于 pg_cron 的異步 SQL 分發

pg_dispatch 由 Snehil Shah 開發，是一個異步任務分發器，定位為 TLE 兼容的 pg_later 替代品，底層依賴 pg_cron。核心函數 pgdispatch.fire(command) 立即異步執行 SQL，pgdispatch.snooze(command, delay) 延遲執行。設計目標是解鎖主事務——當 AFTER INSERT 觸發器需要執行重操作時，將其卸載為后臺任務。

SELECT pgdispatch.snooze('SELECT pg_sleep(20);', '20 seconds');

TLE 兼容（純 PL/pgSQL），可在 Supabase 和 AWS RDS 等沙盒環境使用。依賴 pg_cron >= 1.5。適合觸發器/函數內的異步副作用（通知、異步匯總、寫審計表等），避免長事務占用連接。

21. block_copy_command —— 安全加固：阻止 COPY 命令

block_copy_command 由 rustwizard 開發（Rust/pgrx），通過 ProcessUtility hook 集群范圍內攔截 COPY 命令。在安全敏感環境（PCI-DSS、HIPAA 合規）中防止通過 COPY TO 進行數據外泄或通過 COPY FROM 進行未授權數據導入。

它提供基于角色的 blocklist、方向控制（block_to/block_from），以及對 COPY ... TO PROGRAM 的強制阻斷（默認對所有用戶攔截）。blocked_roles 甚至能阻止 superuser。支持審計日志記錄。

ORDER BY ts DESC;

適用于托管/共享環境（防止租戶用 COPY 導數據）、企業合規（統一攔截與審計）、ETL 權限收斂（通過 GUC/角色配置精確允許導入、阻斷導出）。作者還維護了更全面的命令防火墻擴展 pg_command_fw。

22. pg_isok —— 數據質量的"軟告警"系統

pg_isok（Isok）由 Karl O. Pinc 開發，已在生產環境使用超過十年。它不是傳統約束/觸發器，而是"軟觸發器"式的數據完整性管理：你寫一條能找出可疑數據模式的 SQL，Isok 負責記錄/分類/延后這些發現，并報告"新增問題或已接受數據的變化"，避免你反復審閱同一批歷史問題。

);

與硬約束（拒絕數據）不同，它允許存在可疑數據但持續追蹤和管理——通過 isok_queries 和 isok_results 等表組織工作流，run_isok_queries 函數執行檢查，逐行接受或延遲告警。適合"臟數據導入后逐步清理""業務規則模糊、需要人工裁決"的場景。能寫 SQL 就能上線一套"告警 + 去重 + 延期"機制。

23. external_file —— PostgreSQL 版的 Oracle BFILE

external_file 由 Gilles Darold（HexaCluster Corp）維護，提供與 Oracle BFILE 等效的功能：通過目錄別名 + 文件名的 EFILE 類型引用服務器端外部文件，支持讀取（readEfile()）、寫入（writeEfile()）和復制（copyEfile()）。通過 lo_* 相關機制執行讀寫，并用目錄別名表與權限表控制可訪問范圍。

SELECT writeEfile(my_bytea_column, efilename('MY_DIR', 'output.bin')) FROM my_table;

為 Ora2Pg 遷移場景量身定制，也適合"文件在庫外、元數據在庫內"的遺留系統，以及數據庫側管理外部大對象的批處理導入導出。

24. byteamagic —— 檢測 bytea 的文件類型

byteamagic 由 Nico Mandery 開發，封裝 libmagic（Unix file 命令背后的庫），提供兩個函數：byteamagic_mime(bytea) 返回 MIME 類型，byteamagic_text(bytea) 返回人類可讀的文件描述。

FROM uploads GROUP BY 1 ORDER BY 2 DESC;

當你不得不在表里存 bytea/BLOB 時，可以在 SQL 里識別這段二進制到底是 PDF、PNG 還是其它格式。適合附件/上傳內容治理（識別真實類型、防止偽裝）、Content-Type 自動識別、歷史 BLOB 數據清理等。

25. pg_text_semver —— 語義版本號的原生支持

pg_text_semver 由 Rowan Rodrik van der Molen 開發，基于 text DOMAIN 實現完全符合 Semantic Versioning 2.0.0 規范的版本類型。與 C 實現的 semver 擴展不同，它對版本號各部分沒有 32 位整數的大小限制。

-- (1, 0, 0, 'a.1', 'commit-y')

純 SQL 實現，支持 min/max 聚合和 PGXN Version Range 檢查。適用于擴展/包版本管理、依賴約束校驗、版本分布統計等。

26. parray_gin —— text[] 的子串匹配索引

parray_gin 由 Eugene Seliverstov 開發，為 text[] 數組列提供基于 GIN 索引的部分匹配操作符。標準 PostgreSQL 的 GIN 數組操作符只支持精確元素匹配，parray_gin 新增的 @@> 操作符支持子串包含判斷，底層基于 trigram 分解（復用 pg_trgm 的實現），并通過 recheck 處理 false positive。

SELECT * FROM test_table WHERE val @@> array['%ar%'];

適合標簽系統自動補全、模糊標簽搜索等場景——讓數組模糊匹配進入索引路徑，替代應用層掃描。支持 PG 9.1–18。

27. pg_slug_gen —— 加密安全的時間戳短標識

pg_slug_gen 由 Fernando Olle 開發，生成基于時間戳的加密安全唯一短標識。使用 pg_strong_random() 選擇字符，slug 長度決定時間戳精度：10 字符（秒）、13（毫秒）、16（微秒，默認）、19（納秒）。

SELECT gen_random_slug(19);    -- 納秒精度

注意這不是 URL slug 生成器（從標題轉寫），而是面向"安全短 ID"的方案。適合邀請碼/短鏈接/公開資源 ID（避免自增 ID 暴露業務規模）、分布式寫入（用時間戳維度做可控的無碰撞窗口）等。比 base62(序列) 更難預測。

28. pglock —— PostgreSQL 內的輕量級分布式鎖

pglock 由 fraruiz 開發，在 PostgreSQL 內部實現輕量級分布式鎖服務。它基于一張鎖表和一組函數（pglock.lock/pglock.unlock/pglock.ttl/pglock.set_serializable）實現，支持 TTL 過期機制（默認 5 分鐘），可選配合 pg_cron 定時執行 pglock.ttl() 清理過期鎖。建議使用 SERIALIZABLE 隔離級別以保證并發語義正確。

SELECT pglock.ttl();

無需外部依賴（Redis、ZooKeeper 等），適用于多實例應用搶占任務/資源（定時任務、冪等消費者）、Leader 選舉、防止重復任務執行等場景。鎖行為與業務寫入可在同一數據庫生態里治理。純 SQL 實現。

29. regresql —— 與語言無關的 SQL 回歸測試工具

regresql 由 boringSQL（Radim Marek）開發，是一個獨立的 CLI 工具（Go 編寫），不是 PostgreSQL 擴展。它掃描項目中的 *.sql 文件，運行它們并保存輸出快照與 EXPLAIN 計劃基線，后續運行時對比差異，在 CI 中捕獲查詢結果變化與性能回退。支持 JUnit/GitHub Actions/pgTAP 輸出格式。

SELECT * FROM users WHERE active = true;

工作流圍繞 discover/add/update/test/baseline/snapshot 等命令組織。適合圍繞 SQL 的快照測試（遷移/重構后快速發現結果差異）、EXPLAIN 基線（在 CI 里抓 plan flip 或 seq scan 退化）、把"SQL 真正確認過的輸出"版本化。

30. pgcalendar —— 循環日程的無限投影

pgcalendar 由 h4kbas 開發，提供完整的循環事件日歷系統：事件（events）是邏輯實體，日程（schedules）定義循環模式（每日/每周/每月/每年），投影（projections）生成實際發生時間，例外（exceptions）修改單個實例（取消、改期）。

);

"無限投影""多段 schedule 配置切換""例外處理"這類能力在排班、會議、計費周期等場景很常見，但靠應用層自己拼往往細節爆炸。把日程邏輯放數據庫后，權限、審計與一致性約束更容易統一。

31. pg_variables —— 比臨時表更快的會話變量

pg_variables 由 Postgres Professional 開發，提供會話級變量支持，涵蓋標量、數組和記錄（集合）類型。變量按命名包（package）組織，"是否事務性"可配置：默認變量不隨 BEGIN/ROLLBACK 回滾，但 is_transactional = true 時遵守 ROLLBACK/SAVEPOINT。

SELECT * FROM pgv_select('pack', 'employees');

作為臨時表的高性能替代，避免了目錄膨脹（catalog bloat）。適合復雜存儲過程/批處理中保存中間狀態、連接級信息緩存，也作為其它擴展的基礎設施（如 pgelog 用它緩存 dblink 連接）。

32. pgelog —— 回滾也丟不掉的日志

pgelog 由 anfiau 開發，通過 dblink 實現偽自治事務，使日志記錄在調用事務回滾時依然存活。這解決了 PL/pgSQL EXCEPTION 塊中的日志在 ROLLBACK 后丟失的經典問題。dblink 連接通過 pg_variables 做會話級緩存優化。

SELECT pgelog_set_param('pgelog_ttl_minutes', '2880');

關鍵流程審計時，你不想因為業務事務回滾就丟失診斷線索。批處理/遷移腳本中，階段性日志比單純 RAISE NOTICE 更可查詢。依賴 dblink 和 pg_variables 擴展，每個會話可能額外打開一個連接，需評估 max_connections。

總結

這 33 個擴展背后有幾條清晰的趨勢線。

第一，PostgreSQL 正在通過擴展把"專業對象"內建化。 BSON、Protobuf、RDF、循環日程、化學分子、圖/本體關系——這些擴展把數據庫從"結構化表"推向"可查詢的復雜對象存儲"。權限、審計、備份、事務語義都沿用數據庫基礎設施，減少了數據搬運和外部服務依賴。

第二，查詢能力在向"組合式 API"演化。 RRF 融合、SQL 模板樹、查詢重寫、稀疏計算、近似摘要結構——這些擴展的共同目標是讓復雜邏輯以更少、更穩定的 SQL 片段表達，同時保持可審計、可復跑和可優化。

第三，生產工程與平臺化在加速。 從 pg_stat_ch 的實時遙測外送、pg_datasentinel 的容器資源可見性，到 block_copy_command 的安全鉤子、pg_isok 的軟告警治理——擴展層正在承接越來越多"原本要靠外部系統"的能力。

第四，垂直領域滲透持續加深。 從化學信息學（rdkit）、水文分析（pghydro）到哈薩克語 NLP（pg_kazsearch），PostgreSQL 正在成為越來越多專業領域的計算底座。

第五，新語言運行時的探索值得關注。 pg_typescript 將 Deno/V8 嵌入 PostgreSQL 的實驗，可能預示著存儲過程開發體驗的下一次變革——數據庫函數第一次可以用與應用層完全相同的語言和工具鏈來編寫。

PostgreSQL 的擴展生態就是這樣：既有大教堂（Apache 基金會項目），也有集市（個人開發者的周末項目），共同構建著世界上最先進的開源數據庫。

數據庫老司機

點一個關注 ??，精彩不迷路

對 PostgreSQL， Pigsty，下云 感興趣的朋友

歡迎加入 PGSQL x Pigsty 交流群（搜pigsty-cc）