PostgreSQL扩展终极指南:504个扩展全景解析与32个新增硬核扩展详解
从一个化学扩展说起
一切始于两天前的一则GitHub Issue。一位用户在使用RDKit——化学信息学领域无可争议的标准库时遇到了难题。虽然该库能在PostgreSQL中实现分子结构存储、子结构检索和相似性计算等核心功能,但PGDG官方打包版本竟然缺失了关键的InChI功能。这位用户花费了大量时间折腾编译参数,最终虽勉强跑通,但仍希望Pigsty能提供原生支持。

RDKit确实是一块难啃的硬骨头。大约两年前我曾尝试将其纳入Pigsty的扩展仓库,目标是从Debian移植到EL系列系统。但现实很残酷:Boost、Eigen、RapidJSON、Cairo等依赖项环环相扣,再加上InChI、Avalon等可选模块,每个组件都有独立的编译开关和操作系统兼容性问题。几番尝试未果后,我只能暂时搁置。
然而这次情况截然不同——Coding Agent时代已经到来。
借助Codex / Claude Code处理这类"构建系统考古"任务堪称降维打击。过去需要反复试错数周的工作,如今只需一两轮对话就能自动完成。在最新版本中,我不仅解决了PGDG打包的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]
| 分类 | All | PGDG | PIGSTY | CONTRIB | MISS | PG18 | PG17 | PG16 | PG15 | PG14 |
|---|---|---|---|---|---|---|---|---|---|---|
| 全部 | 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 |
这五百多个扩展的构成颇具深意:约70个是PostgreSQL自带的Contrib扩展,150个来自PGDG官方打包,剩下的330个全部由我个人维护构建。可以说,在PostgreSQL扩展生态这个赛道上,Pigsty已经做到了前所未有的深度和广度。
横向对比更能体现这一成就的分量。主流云服务商如Supabase,在去除PG自带的35个Contrib扩展后,实际提供的第三方PG扩展不足30个。这意味着Pigsty的扩展数量是商业产品的十倍以上。
新扩展全景扫描
本次新增的32个扩展技术密度极高,可归为四大类别:
数据域革命:将化学分子、RDF三元组、BSON、Protobuf、循环日程等复杂对象提升为数据库一等公民,彻底打破传统关系模型的边界。
查询能力跃升:涵盖稀疏线性代数与图算法、Datalog图查询引擎、全文检索增强、混合排序融合、递归SQL模板引擎等前沿能力。
生产工程化:提供深度可观测性、查询遥测实时导出、CDC到MQTT协议转换、COPY命令安全拦截、DDL逻辑复制补全、轻量级分布式锁、软告警式数据质量治理等企业级特性。
开发者体验革新:包括会话级变量管理、伪自治事务日志系统、自然语言时间解析,以及最具颠覆性的——在数据库内部直接运行TypeScript代码。
这些扩展共同指向一个明确的演进方向:PostgreSQL正通过其强大的扩展层,从单纯的数据库进化为连接应用层与数据平台的中间枢纽。越来越多的原本需要独立服务解决的复杂问题,如今可以在单条SQL事务边界内一站式完成。
这就是PostgreSQL极致可扩展性的终极魅力。
新扩展技术详解
本章节由Claude、Codex、Gemini三大AI助手协同完成,为读者快速掌握每个扩展的核心功能、技术实现与适用场景提供精准导航。
- rdkit —— 化学信息学的数据库原生革命
RDKit作为开源化学信息学的行业标准库,由Greg Landrum创立(前身为诺华制药项目,现归属T5 Informatics)。其PostgreSQL插件模块将分子结构存储、子结构检索与相似性计算直接融入关系型数据库,使制药企业和化学研究机构能够用标准SQL查询数百万级化合物库,彻底摆脱对外部工具链的依赖。
核心数据类型包括**mol(分子对象)和qmol(查询分子/SMARTS模式),以及bfp/sfp(位指纹/稀疏指纹)。运算符体系丰富:@>执行子结构匹配,%实现Tanimoto相似度判断,<%>作为距离运算符。所有操作均可通过GiST索引**加速——索引层基于指纹预过滤实现快速剪枝,再进行精确匹配。关键函数如mol_from_smiles()、morganbv_fp()(Morgan指纹生成)、tanimoto_sml()等,配合rdkit.tanimoto_threshold等GUC参数可精细调控检索灵敏度。
以ChEMBL数据库(187万化合物)为例:
-- 子结构检索:查找含特定骨架的分子SELECT count(*) FROM rdk.mols WHERE m @> 'c1cccc2c1nncc2';-- 返回:461个匹配,耗时约108ms
-- Tanimoto相似性搜索:基于Morgan指纹SELECT molregno, tanimoto_sml(morganbv_fp(mol_from_smiles('c1ccccc1C(=O)NC'::cstring)), mfp2) AS similarityFROM rdk.fps JOIN rdk.mols USING (molregno)WHERE morganbv_fp(mol_from_smiles('c1ccccc1C(=O)NC'::cstring)) % mfp2ORDER BY morganbv_fp(mol_from_smiles('c1ccccc1C(=O)NC'::cstring)) <%> mfp2;
-- SMARTS模式匹配:检索噁二唑或噻二唑类化合物SELECT * FROM rdk.mols WHERE m @> 'c1[o,s]ncn1'::qmol LIMIT 500;
应用场景覆盖药物研发全流程:先导化合物骨架搜索(百万级库的子结构匹配)、SAR分析(通过相似性查找活性类似物)、化合物注册系统(利用指纹进行重复性检查)、商业化合物目录检索(如eMolecules 600万+数据集)。
工程实践要点:cartridge的核心价值不在于"能否计算",而在于"能否被索引、能否被查询规划器正确优化"。索引策略与查询模板需要预先固化,否则极易写出语义正确但性能灾难的结构过滤。在187万化合物规模上,子结构检索耗时88ms至1900ms不等,经充分优化可支撑600万+化合物的查询负载。项目采用BSD许可证,提供Docker镜像(如mcs07/postgres-rdkit)和conda安装方案。
- 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采样,再到借助d4、c2d等外部求解器进行d-DNNF编译。
-- 安全等级传播:查询结果自动继承最高安全级别SELECT create_provenance_mapping('personnel_level', 'personnel', 'classification');SELECT p1.city, security(provenance(), 'personnel_level')FROM personnel p1, personnel p2WHERE p1.city = p2.city AND p1.id < p2.idGROUP BY p1.city ORDER BY p1.city;
-- 布尔公式溯源:每行结果显示其推导公式SELECT *, formula(provenance(), 'witness_mapping') FROM s;
-- 概率查询:计算结果行可信度SELECT city, probability_evaluate(provenance()) FROM result;
适用场景四类:安全分级传播——查询结果自动继承源数据最高安全等级;概率数据库——基础数据带可信度评分时计算查询结果正确概率;数据血缘审计——精确追踪结果行来源元组,支持PROV-XML标准导出;可信度评估——如刑事调查场景,通过溯源加权评估目击者陈述可靠性。
ProvSQL的真正价值在于"可组合性":溯源结果非字符串日志,而是可被函数持续处理的对象。建议部署于关键链路(核心报表/模型特征/合规计算),而非全库无差别开启。采用C/C++实现(依赖Boost库),溯源电路存储于共享内存。支持PG 10–18,MIT许可证。
- onesparse —— 十亿边级图算法的SQL原生方案
OneSparse将高性能稀疏线性代数库SuiteSparse:GraphBLAS引入PostgreSQL,由GraphBLAS C API委员会成员Michel Pelletier主导开发,技术顾问包括SuiteSparse作者Timothy A. Davis教授(SIAM/ACM/IEEE Fellow)。核心理念是将图表示为稀疏矩阵,通过矩阵乘法实现BFS、PageRank、三角中心性等图算法,且完全在SQL中完成。
扩展引入matrix(稀疏矩阵)、vector(稀疏向量)、scalar、semiring、monoid等数据类型,提供@(矩阵乘法/plus_times半环)等运算符。内置算法库来自LAGraph,包括BFS(层级与父节点双模式)、PageRank、三角中心性、度中心性、单源最短路径等。技术实现上,将GraphBLAS的不透明句柄封装于PostgreSQL的Expanded Object Header结构,小图(<1GB)采用TOAST存储,大图支持Large Object或文件系统。内置JIT编译器支持NVIDIA CUDA GPU加速。
-- 从Matrix Market文件加载图SELECT mmread('/home/postgres/onesparse/demo/karate.mtx') AS graph;
-- BFS遍历SELECT (bfs(graph, 1)).level FROM karate;
-- 度中心性(矩阵列归约)SELECT reduce_cols(cast_to(graph, 'int32')) AS degree FROM karate;
-- PageRank计算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许可证。
- pg_datasentinel —— 容器化时代的深度可观测性解决方案
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查询。
-- 查看各后端内存使用(增强版pg_stat_activity)SELECT pid, usename, query, backend_memory_bytes, temp_file_bytesFROM pg_datasentinel_activity;
-- 容器资源实时监控SELECT cpu_quota, memory_limit, memory_usage, cpu_pressureFROM pg_datasentinel_container_resources;
-- 事务回卷风险预估SELECT xid_current, xid_limit, xid_eta_aggressive_vacuum, xid_eta_wraparoundFROM pg_datasentinel_wraparound;
对于Kubernetes上运行PostgreSQL的团队,pg_datasentinel提供了无需外部监控代理的容器级资源可见性。XID回卷预警功能堪称运维神兵——众所周知,XID回卷会导致数据库强制关机,而pg_datasentinel通过追踪消耗速率提供预测性告警,将"被动救火"变为"主动防火"。采用3-Clause BSD许可证,要求PG 15+。
- datasketches —— Apache出品的亿级数据近似分析神器
Apache DataSketchse是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)二进制兼容。
-- 近似去重计数:比精确COUNT(DISTINCT)快约6倍SELECT cpc_sketch_distinct(id) FROM random_ints_100m;-- 结果:63423695(精确值:63208457),耗时~20s vs 精确~2min
-- Theta Sketch集合运算:计算两用户群体交集SELECT theta_sketch_get_estimate( theta_sketch_intersection(sketch1, sketch2)) FROM theta_set_op_test;
-- KLL分位数估算:获取中位数SELECT kll_float_sketch_get_quantile(sketch, 0.5) FROM kll_float_sketch_test;
-- 多维度聚合+Sketch合并SELECT cpc_sketch_get_estimate(cpc_sketch_union(respondents_sketch)) AS num_respondents, flavorFROM ( SELECT cpc_sketch_build(respondent) AS respondents_sketch, flavor, country FROM (VALUES (1,'Vanilla','CH'),(1,'Chocolate','CH'), (2,'Chocolate','US'),(2,'Strawberry','US')) AS t(respondent, flavor, country) GROUP BY flavor, country) bar GROUP BY flavor;
典型用例:实时UV统计——不存储用户ID即可跨时间窗口合并去重;分布分析——在数十亿事件上计算p50/p95/p99延迟无需排序;受众重叠分析——用Theta Sketch交集运算计算"看过广告A且访问网站B"的用户数。在1亿行数据上,CPC Sketch去重计数约20秒完成(精确COUNT(DISTINCT)约2分钟),相对误差控制在个位数百分比内。
- 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_input_data_drainage_line('public', 'input_drainage_line', 'geom', 'nome');
-- 计算流向并自动修正不一致河段SELECT pghydro.pghfn_CalculateFlowDirection();SELECT pghydro.pghfn_ReverseDrainageLine();
-- 计算Pfafstetter流域编码SELECT pghydro.pghfn_Calculate_Pfafstetter_Codification();
-- 计算上游汇水面积和入海距离SELECT pghydro.pghfn_CalculateUpstreamArea();SELECT pghydro.pghfn_CalculateDistanceToSea(0);
-- Strahler河流分级SELECT pghydro.pghfn_calculatestrahlernumber();
适用于国家级水文数据库管理、流域规划与编码、上下游污染影响分析(如定位污染源上游所有河段)、排水网络拓扑一致性验证。它本质上是一套专业领域的数据库内ETL/分析流水线——数据在PostGIS中统一管理,分析过程SQL自动化,当原始地形/河网数据更新时,按函数流水线重算比手工脚本可靠得多。配合QGIS的PgHydroTools插件实现可视化交互。完全用PL/pgSQL编写,GPLv2许可证。
- pg_stat_ch —— ClickHouse官方出品的查询遥测利器
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设计哲学一致。
-- PostgreSQL侧:监控扩展健康状态SELECT * FROM pg_stat_ch_stats();-- 返回:enqueued, exported, dropped计数,最后成功/失败时间戳
-- ClickHouse侧:过去1小时按应用统计p95/p99SELECT query_id, count() AS calls, quantile(0.95)(duration_us) / 1000 AS p95_ms, quantile(0.99)(duration_us) / 1000 AS p99_msFROM pg_stat_ch.events_rawWHERE app = 'myapp' AND ts_start > now() - INTERVAL 1 HOURGROUP 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许可证。
- pg_rrf —— 混合检索排序融合的一行函数方案
pg_rrf由日本开发者yuiseki开发(2026年1月发布),Rust(pgrx)实现。它将**Reciprocal Rank Fusion(RRF)**算法封装为原生PostgreSQL函数,解决混合检索中"分数不可比"的工程痛点:不同检索器输出尺度各异,直接加权难以调优,而RRF仅依赖排名。公式为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使用该路排名计算得分。
-- 使用pg_rrf实现混合检索:pgvector + BM25WITH fused AS ( SELECT * FROM rrf_fuse( ARRAY(SELECT id FROM docs ORDER BY bm25_score DESC LIMIT 100), ARRAY(SELECT id FROM docs ORDER BY embedding <=> :qvec LIMIT 100), 60 ))SELECT d.*, fused.scoreFROM fused JOIN docs d USING (id)ORDER BY fused.score DESC LIMIT 20;
这将原本需要FULL OUTER JOIN + COALESCE链+手动评分公式的20+行CTE压缩为单行函数调用。应用场景覆盖RAG混合检索(语义+全文融合)、电商产品搜索、多信号文档排序等。将融合逻辑下推到数据库层,特别是当结果需继续JOIN业务表时,显著减少应用层拼接与排序开销。当前v0.0.3,MIT许可证。
- pg_kazsearch —— 哈萨克语全文检索的零突破
pg_kazsearch是PostgreSQL首个哈萨克语全文检索扩展。哈萨克语作为高度黏着语,单词如мектептерімізде承载复数、领属、位格等多重后缀,必须完全剥离才能到达词根мектеп。现有PostgreSQL或Elasticsearch分析器均无法处理此特性。
扩展采用Rust(pgrx)实现,提供kazakh_cfg文本搜索配置和pg_kazsearch_dict词典。词干提取算法基于BFS后缀剥离,配合元音和谐验证和源自Apertium-kaz的21,863个词性标注词根词典防止过度词干化。运行时可通过ALTER TEXT SEARCH DICTIONARY动态调整权重参数。
-- 词干提取演示SELECT ts_lexize('pg_kazsearch_dict', 'алмаларымыздағы');-- 返回:{алма}
-- 构建带权重tsvector并检索SELECT title FROM articlesWHERE fts @@ websearch_to_tsquery('kazakh_cfg', 'президенттің жарлығы')ORDER BY ts_rank_cd(fts, websearch_to_tsquery('kazakh_cfg', 'президенттің жарлығы')) DESCLIMIT 10;
在2,999篇文章基准测试中,查询延迟0.5ms(比pg_trgm快2.8倍),nDCG@10提升25%,Recall@10提升23%。适用于哈萨克语新闻/政府文档检索、电商搜索等场景——在多语种系统中补齐"低资源语言"检索能力,避免退化为粗糙的trigram模糊匹配。
- pg_liquid —— Datalog风格的声明式图查询
pg_liquid由Michael Golfi(西雅图)开发,将Liquid/Datalog风格的声明式图查询带入PostgreSQL。通过liquid.query(...)单次调用即可声明事实、定义规则并执行查询,无需部署独立图数据库。规则为query-local(仅单次liquid.query有效),支持事实断言、递归传递闭包、复合查询(compounds)和行规范化器。
SELECT targetFROM liquid.query($$ Edge("a", "path", "b"). Edge("b", "path", "c"). Edge("c", "path", "d").
Reach(x, y) :- Edge(x, "path", y). Reach(x, z) :- Reach(x, y), Reach(y, z).
Reach("a", target)?$$) AS t(target text)ORDER BY 1;
扩展支持本体谓词定义(如DefPred)与compound(如OntologyClaim@(...))结合,通过compound携带溯源/置信信息,依靠规则实现subclass closure等推理。适用于知识图谱查询、层级数据遍历(组织架构、分类树)、基于规则的业务逻辑系统等场景——当不想引入重量级图引擎时,用扩展补齐最关键的递归查询能力。完全用PL/pgSQL实现,无外部依赖,项目处于早期阶段。
- 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实现表和命令级别的精细化捕获控制。
-- 发布端配置INSERT INTO logical_ddl.settings (publish, source) VALUES (true, 'publisher1');
-- 将逻辑复制所有表加入DDL追踪INSERT INTO logical_ddl.publish_tablelist (relid)SELECT prrelid FROM pg_catalog.pg_publication_rel;
-- 按表指定捕获DDL类型INSERT INTO logical_ddl.publish_tablelist (relid, cmd_list)VALUES ('my_table'::regclass, ARRAY['ADD COLUMN', 'DROP COLUMN']);
适用于逻辑复制环境的自动化DDL同步、零停机迁移、多数据中心PostgreSQL架构等。将"DDL同步"从流程管理变为可审计的数据流,显著降低复制事故概率。MIT许可证,PGXN可用。约束、索引、默认值等尚未实现。
- 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。
-- 创建指向DBpedia的外部服务器CREATE SERVER dbpedia FOREIGN DATA WRAPPER rdf_fdw OPTIONS (endpoint 'https://dbpedia.org/sparql');
-- 创建外部表映射SPARQL查询CREATE FOREIGN TABLE dbpedia_query ( p rdfnode OPTIONS (variable '?p'), o rdfnode OPTIONS (variable '?o')) SERVER dbpedia OPTIONS ( sparql 'SELECT ?p ?o WHERE {<http://dbpedia.org/resource/Berlin> ?p ?o}');
-- 用标准SQL查询RDF数据SELECT * FROM dbpedia_query WHERE o = 'some_value' LIMIT 10;
rdf_fdw_clone_table()存储过程支持将外部表数据分批克隆到本地表。实现层面会将拉取数据加载到内存再转换,面对大规模数据需谨慎评估内存与下推效果。适合关联数据集成(DBpedia、Wikidata)、用SQL/BI工具链直接消费SPARQL端点等场景。MIT许可证,支持PG 9.5–18。
- pgbson —— 比JSONB更精确的二进制文档存储
pgbson(postgresbson)由buzzmam开发,为PostgreSQL引入原生BSON(Binary JSON)数据类型。相比JSON,BSON提供一等公民的datetime、decimal128、int32/int64、binary等类型,解决分布式系统数据交换中的精度丢失和类型模糊问题,确保二进制完美往返(BSON in = BSON out)。
核心API分两类访问方式:高性能dotpath函数——bson_get_string(bson, 'd.recordId')、bson_get_datetime()、bson_get_decimal128()等,直接在底层结构行走,仅终点分配内存;类似JSON的->/->>链式操作符,但每一步构造中间子结构,深层路径成本放大。配合B-Tree和HASH索引,函数索引可实现10,000倍查询加速(vs顺序扫描)。输入端支持EJSON格式。
-- 插入带丰富类型的EJSON文档INSERT INTO data_collection (data) VALUES ( '{"d":{"recordId":"R1","amt":{"$numberDecimal":"77777809838.97"}, "ts":{"$date":"2022-03-03T12:13:14.789Z"}}}');
-- 函数索引 + dotpath查询(推荐模式)CREATE INDEX ON data_collection(bson_get_string(data, 'd.recordId'));SELECT bson_get_decimal128(data, 'd.amt')FROM data_collection WHERE bson_get_string(data, 'd.recordId') = 'R1';
-- 箭头链式访问(深层路径性能较差)SELECT (data->'d'->'amt'->>'$numberDecimal')::numeric FROM data_collection;
典型场景:跨语言事件/文档管道(Java→Kafka→Python→PostgreSQL)的精确类型保持、金融数据(decimal128精确到分)、数字签名(BSON的确定性二进制格式支持可靠哈希)等。MIT许可证,支持PG 14–18。
- pg_when —— 自然语言时间解析器
pg_when由frectonz开发,将自然语言时间表达解析为PostgreSQL的timestamptz或epoch时间戳。核心函数when_is(text)返回标准timestamp,语法由三部分组成:日期 + at + 时间 + in + 时区。未指定时区时默认为UTC。
SELECT when_is('5 days ago at this hour in Asia/Tokyo');SELECT when_is('next friday at 8:00 pm in America/New_York');SELECT when_is('in 2 months at midnight in UTC-8');SELECT when_is('December 31, 2026 at evening');
另有seconds_at()、millis_at()、micros_at()、nanos_at()返回不同精度的UNIX时间戳。这不是调度器,而是纯解析器。适用于运营/客服系统的"人类时间输入"落库、数据修复/回填脚本中的自然语言时间替代拼写函数、统一时区处理等场景。MIT许可证。
- pgmqtt —— 数据库变更直连MQTT消息总线
pgmqtt由RayElg开发(Rust实现),将PostgreSQL变更(INSERT/UPDATE/DELETE)通过CDC直接转换为MQTT消息推送给订阅者,同时支持MQTT入站消息按映射写回表。它不是通用MQTT客户端,而是将"变更流"与"消息broker"嵌入数据库侧,通过SQL配置topic映射与payload模板。
-- 出站:表变更 → MQTT topic(支持模板化topic和JSON payload)SELECT pgmqtt_add_outbound_mapping( 'public', 'my_table', 'topics/{{ op | lower }}', '{{ columns | tojson }}');
-- 入站:MQTT topic → 表(JSONPath规则映射到列)SELECT pgmqtt_add_inbound_mapping( 'sensor/{site_id}/temperature', 'sensor_readings', '{"site_id": "{site_id}", "value": "$.temperature"}'::jsonb);
IoT场景尤为适用——无需外部中间件即可将数据库状态变化推送至边缘设备,或将传感器数据直接写入表。也适用于事件驱动架构中的轻量级消息分发,减少应用层胶水代码。Elastic License 2.0。
- pg_query_rewrite —— 运行时SQL透明替换引擎
pg_query_rewrite由Pierre Forstmann开发,利用ProcessUtility hook实现SQL语句的运行时透明替换。规则基于精确字符串匹配(大小写和空格敏感)存储于共享内存。
-- 添加重写规则SELECT pgqr_add_rule('select 10;', 'select 11;');
-- 此后执行"select 10;"将返回11SELECT 10; -- 返回11
-- 查看所有规则及重写计数SELECT pgqr_rules();
这是一把"锋利双刃剑":不支持参数化语句、最大长度约32KB、匹配对大小写/空格/分号敏感、规则不持久化(重启丢失,需借助启动SQL机制恢复)。适用于数据库迁移期间对遗留系统固定SQL做透明重定向、危险查询临时拦截、查询A/B测试等。默认最多10条规则,支持PG 9.5–18。
- pgclone —— 数据库对象一键克隆工具
pgclone由valehdba开发(PGXN发布2.0.0版),定位直白:无需pg_dump/pg_restore、无需shell脚本,直接通过SQL函数将表、schema、数据库、函数(甚至角色与权限)从源实例克隆到目标环境。
使用COPY协议实现高速数据传输,支持异步操作与进度跟踪,支持选择性克隆(列/行过滤),DDL全覆盖(索引、约束、触发器、视图、物化视图、序列等),还提供数据脱敏与敏感列自动发现能力。
-- 克隆远程表到本地(含数据)SELECT pgclone_table( 'host=source-server dbname=mydb user=postgres password=secret', 'public', 'customers', true);
-- 克隆整个远程数据库SELECT pgclone_database( 'host=source-server dbname=mydb user=postgres password=secret', true);
适用于开发/测试环境快速搭建(含DDL、索引)、生产到预发的"带脱敏克隆"、多库迁移与验证等。相比pg_dump/pg_restore,它完全在数据库内部完成,极大简化DevOps流程。
- pgproto —— Protocol Buffers原生支持
pgproto由Apaezmx开发,为PostgreSQL提供原生Protocol Buffers(proto3)存储、查询、修改和索引能力。核心机制是"运行时Schema注册 + 二进制遍历":将FileDescriptorSet注册到pb_schemas后,protobuf类型列即可通过路径数组提取嵌套字段。引入->字段导航、#>嵌套路径访问、||消息合并等操作符,以及pb_set()/pb_insert()/pb_delete()/pb_to_json()等函数。
-- 嵌套字段提取SELECT data #> '{Outer, inner, id}'::text[] FROM items;
-- 局部更新(返回新protobuf值)UPDATE items SET data = pb_set(data, ARRAY['Outer', 'a'], '42');
-- B-Tree表达式索引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。
- 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权限。
-- 定义模板INSERT INTO fsql.templates (path, cmd, body)VALUES ('user_count','exec', 'SELECT jsonb_build_object(''total'', count(*)) FROM users WHERE status = {d[status]!r}');
-- 执行模板SELECT fsql.run('user_count', '{"status":"active"}');
-- 渲染但不执行(dry-run)SELECT fsql.render('user_count', '{"status":"active"}');
这不是函数式SQL,而是层次化模板引擎:目标是用JSON请求体驱动SQL生成,减少应用层代码分支。适用于动态报表生成、ETL管道编排、多租户查询生成、将差异化SQL固化在模板表中配合权限管理等场景。
- 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.fire('SELECT pg_sleep(40);');SELECT pgdispatch.snooze('SELECT pg_sleep(20);', '20 seconds');
TLE兼容(纯PL/pgSQL),可在Supabase、AWS RDS等沙盒环境使用。依赖pg_cron >= 1.5。适合触发器/函数内的异步副作用(通知、异步汇总、写审计表等),避免长事务占用连接。
- 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。支持完整审计日志。
COPY my_table TO STDOUT; -- 非superuser:ERRORCOPY (SELECT 1) TO PROGRAM 'cat'; -- 默认:对所有用户阻断
-- 查看审计日志SELECT ts, current_user_name, copy_direction, blocked, block_reasonFROM block_copy_command.audit_logWHERE ts > now() - interval '1 hour'ORDER BY ts DESC;
适用于托管/共享环境(防止租户用COPY导数据)、企业合规(统一拦截与审计)、ETL权限收敛(通过GUC/角色配置精确允许导入、阻断导出)。作者同时维护更全面的命令防火墙扩展pg_command_fw。
- pg_isok —— 数据质量的"软触发器"体系
pg_isok(Isok)由Karl O. Pinc开发,已在生产环境稳定运行超过十年。它不同于传统约束/触发器,而是"软触发器"式数据完整性管理:你编写SQL找出可疑数据模式,Isok负责记录/分类/延后这些发现,并报告"新增问题或已接受数据的变化",避免反复审阅历史问题。
-- 典型Isok查询:找出"客户无订单"可疑模式INSERT INTO isok.isok_queries (query) VALUES ( 'SELECT customers.id::text, ''Customer '' || customers.id || '' has no related ORDERS'', NULL FROM customers WHERE NOT EXISTS ( SELECT 1 FROM orders WHERE orders.customerid = customers.id )');
与硬约束(拒绝数据)不同,它允许可疑数据存在但持续追踪——通过isok_queries和isok_results表组织工作流,run_isok_queries函数执行检查,逐行接受或延迟告警。适合"脏数据导入后逐步清理"“业务规则模糊需人工裁决"场景。能写SQL即可上线一套"告警+去重+延期"机制。
- external_file —— PostgreSQL版Oracle BFILE
external_file由Gilles Darold(HexaCluster Corp)维护,提供与Oracle BFILE等效功能:通过目录别名+文件名的EFILE类型引用服务器端外部文件,支持读取(readEfile())、写入(writeEfile())和复制(copyEfile())。通过lo_*机制执行读写,用目录别名表与权限表控制访问范围。
-- 注册目录INSERT INTO directories(directory_name, directory_path) VALUES ('MY_DIR', '/data/files/');
-- 读取外部文件SELECT readEfile(efilename('MY_DIR', 'document.pdf'));
-- 将bytea列写入外部文件SELECT writeEfile(my_bytea_column, efilename('MY_DIR', 'output.bin')) FROM my_table;
为Ora2Pg迁移场景量身定制,也适合"文件在库外、元数据在库内"的遗留系统,以及数据库侧管理外部大对象的批处理导入导出。
- byteamagic —— bytea内容的文件类型侦探
byteamagic由Nico Mandery开发,封装libmagic(Unix file命令底层库),提供两个函数:byteamagic_mime(bytea)返回MIME类型,byteamagic_text(bytea)返回人类可读的文件描述。
SELECT byteamagic_mime(file_data) FROM file_storage WHERE id = 1;-- 'image/png'
SELECT byteamagic_mime(data) AS mime_type, count(*)FROM uploads GROUP BY 1 ORDER BY 2 DESC;
当不得不在表中存储bytea/BLOB时,可在SQL层面识别二进制真实类型(PDF、PNG等)。适合附件/上传内容治理(识别真实类型、防止伪装)、Content-Type自动识别、历史BLOB数据清理等。
- pg_text_semver —— 无限制的语义版本号类型
pg_text_semver由Rowan Rodrik van der Molen开发,基于text DOMAIN实现完全符合Semantic Versioning 2.0.0规范的版本类型。与C实现的semver扩展不同,它对版本号各部分无32位整数大小限制。
SELECT '0.9.3'::semver < '0.11.2'::semver; -- true(语义比较,非字典序)SELECT '1.0.0-alpha'::semver < '1.0.0'::semver; -- true(预发布 < 正式版)SELECT '8.8.8+bla'::semver = '8.8.8'::semver; -- true(构建元数据忽略)SELECT semver_parsed('1.0.0-a.1+commit-y');-- (1, 0, 0, 'a.1', 'commit-y')
纯SQL实现,支持min/max聚合和PGXN版本范围检查。适用于扩展/包版本管理、依赖约束校验、版本分布统计等。
- parray_gin —— text[]数组的子串匹配索引
parray_gin由Eugene Seliverstov开发,为text[]数组列提供基于GIN索引的部分匹配操作符。标准PostgreSQL GIN数组操作符仅支持精确元素匹配,parray_gin新增的@@>操作符支持子串包含判断,底层基于trigram分解(复用pg_trgm实现),通过recheck处理误报。
CREATE INDEX ON test_table USING gin (val parray_gin_ops);
-- 'post'子串匹配'postgresql'SELECT * FROM test_table WHERE val @@> array['post'];
-- 支持LIKE模式的部分包含SELECT * FROM test_table WHERE val @@> array['%ar%'];
适合标签系统自动补全、模糊标签搜索等场景——让数组模糊匹配进入索引路径,替代应用层扫描。支持PG 9.1–18。
- pg_slug_gen —— 加密安全的时间戳短标识生成器
pg_slug_gen由Fernando Olle开发,生成基于时间戳的加密安全唯一短标识。使用pg_strong_random()选择字符,slug长度决定时间戳精度:10字符(秒)、13(毫秒)、16(微秒,默认)、19(纳秒)。
SELECT gen_random_slug(); -- 微秒精度SELECT gen_random_slug(10); -- 秒精度SELECT gen_random_slug(19); -- 纳秒精度
注意这不是URL slug生成器(从标题转写),而是"安全短ID"方案。适合邀请码/短链接/公开资源ID(避免自增ID暴露业务规模)、分布式写入(时间戳维度提供可控无碰撞窗口)等。比base62(序列)更难预测。
- pglock —— PostgreSQL内的轻量级分布式锁
pglock由fraruiz开发,在PostgreSQL内部实现轻量级分布式锁服务。基于锁表和一组函数(pglock.lock/pglock.unlock/pglock.ttl/pglock.set_serializable)实现,支持TTL过期机制(默认5分钟),可选配合pg_cron定时执行pglock.ttl()清理过期锁。建议使用SERIALIZABLE隔离级别保证并发语义正确性。
-- 获取锁SELECT pglock.lock('b3d8a762-3a0e-495b-b6a1-dc8609839f7b', 'users');
-- 释放锁SELECT pglock.unlock('b3d8a762-3a0e-495b-b6a1-dc8609839f7b', 'users');
-- 清理过期锁SELECT pglock.ttl();
无需外部依赖(Redis、ZooKeeper等),适用于多实例应用抢占任务/资源(定时任务、幂等消费者)、Leader选举、防止重复任务执行等场景。锁行为与业务写入可在同一数据库生态中统一治理。纯SQL实现。
- regresql —— 语言无关的SQL回归测试框架
regresql由boringSQL(Radim Marek)开发,是独立CLI工具(Go编写),非PostgreSQL扩展。它扫描项目中的*.sql文件,运行并保存输出快照与EXPLAIN计划基线,后续运行时对比差异,在CI中捕获查询结果变化与性能回退。支持JUnit/GitHub Actions/pgTAP输出格式。
-- 在.sql文件中用注释标记查询名称-- name: get-user-by-idSELECT * FROM users WHERE id = :id;
-- name: list-active-usersSELECT * FROM users WHERE active = true;
工作流围绕discover/add/update/test/baseline/snapshot等命令组织。适合SQL快照测试(迁移/重构后快速发现结果差异)、EXPLAIN基线(CI中捕获plan flip或seq scan退化)、将"SQL确认过的输出"版本化管理。
- pgcalendar —— 无限投影的循环日程系统
pgcalendar由h4kbas开发,提供完整的循环事件日历系统:事件(events)是逻辑实体,日程(schedules)定义循环模式(每日/每周/每月/每年),投影(projections)生成实际发生时间,例外(exceptions)修改单个实例(取消、改期)。
-- 创建事件和日程INSERT INTO pgcalendar.events (name, description, category)VALUES ('Daily Standup', 'Team standup meeting', 'meeting');
INSERT INTO pgcalendar.schedules (event_id, start_date, end_date, recurrence_type, recurrence_interval)VALUES (1, '2024-01-01 09:00:00', '2024-12-31 23:59:59', 'daily', 1);
-- 投影:生成一周实际发生时间SELECT * FROM pgcalendar.get_event_projections(1, '2024-01-01', '2024-01-07');
-- 添加例外:取消某天INSERT INTO pgcalendar.exceptions (schedule_id, exception_date, exception_type, notes)VALUES (1, '2024-01-15', 'cancelled', 'Holiday');
-- 切换日程配置SELECT pgcalendar.transition_event_schedule( p_event_id := 1, p_new_start_date := '2024-02-01 09:00:00', p_new_end_date := '2024-06-30 23:59:59', p_recurrence_type := 'weekly', p_recurrence_interval := 2, p_recurrence_day_of_week := 1);
“无限投影"“多段schedule配置切换"“例外处理"这类能力在排班、会议、计费周期等场景极为常见,但应用层自行实现往往细节爆炸。将日程逻辑下沉到数据库后,权限、审计与一致性约束更容易统一管理。
- pg_variables —— 比临时表高效的会话变量
pg_variables由Postgres Professional开发,提供会话级变量支持,涵盖标量、数组和记录(集合)类型。变量按命名包(package)组织,“是否事务性"可配置:默认变量不随BEGIN/ROLLBACK回滚,但is_transactional = true时遵守ROLLBACK/SAVEPOINT语义。
SELECT pgv_set('vars', 'int1', 101);SELECT pgv_get('vars', 'int1', NULL::int); -- 返回101
-- 事务性变量:跟随SAVEPOINT回滚BEGIN;SELECT pgv_set('vars', 'tx_val', 101, true);SAVEPOINT sp1;SELECT pgv_set('vars', 'tx_val', 102, true);ROLLBACK TO sp1;COMMIT;SELECT pgv_get('vars', 'tx_val', NULL::int); -- 返回101
-- 记录集合操作SELECT pgv_insert('pack', 'employees', row(1, 'Alice'::text));SELECT * FROM pgv_select('pack', 'employees');
作为临时表的高性能替代,避免目录膨胀(catalog bloat)。适合复杂存储过程/批处理中的中间状态保存、连接级信息缓存,也作为其它扩展的基础设施(如pgelog用它缓存dblink连接)。
- pgelog —— 回滚不丢的自治事务日志
pgelog由anfiau开发,通过dblink实现伪自治事务,使日志记录在调用事务回滚时依然持久化。这解决了PL/pgSQL EXCEPTION块中日志在ROLLBACK后丢失的经典问题。dblink连接通过pg_variables做会话级缓存优化。
-- 即使外层事务回滚,日志依然保留DO $$BEGIN PERFORM 1/0; -- 触发除零错误EXCEPTION WHEN OTHERS THEN PERFORM pgelog_to_log('FAIL', 'my_func', 'division by zero', '1', SQLERRM, SQLSTATE); RAISE;END $$;
-- 查询日志SELECT log_stamp, log_info FROM pgelog_logs ORDER BY log_stamp DESC LIMIT 5;
-- 配置日志TTLSELECT pgelog_set_param('pgelog_ttl_minutes', '2880');
关键流程审计时,业务事务回滚不应丢失诊断线索。批处理/迁移脚本中,阶段性日志比单纯RAISE NOTICE更具查询价值。依赖dblink和pg_variables扩展,每个会话可能额外打开一个连接,需评估max_connections影响。
技术趋势总结
这32个新星扩展背后浮现出五条清晰的技术演进脉络。
第一,专业化对象的数据库原生内化。从化学分子、RDF三元组、BSON、Protobuf到循环日程,这些扩展将PostgreSQL从"结构化表存储"推向"可查询的复杂对象容器”。权限、审计、备份、事务语义等基础设施复用数据库原生能力,大幅削减数据搬运和外部服务依赖。
第二,查询能力向组合式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基金会项目),也有集市(个人周末项目),共同构建着世界上最先进的开源数据库。