PGXN v2

来自 PostgreSQL 维基
跳转到导航跳转到搜索

PGXN v2 是一个重新思考和重新实现 PGXN 的总项目代号。

背景

PGXN 是由 Theory 于 2011 年创建的,他根据 CPAN 的设计,并为 Postgres 扩展实现了它。在 2012 年初的一波活动和发布之后,该服务一直保持相对稳定和不变,一直在运行,在时间允许的情况下分发扩展以及定期进行错误修复和维护。

PGXN 充其量只是一次中等程度的成功。它可靠地服务了它的目的,持续了 12 年,但从未实现成为开源 Postgres 扩展的记录来源的目标。截至 2024 年春季,它的 关于页面 统计了 390 个扩展,而一个手动维护的 扩展列表 统计了超过 1000 个公开可用的扩展。一些流行的扩展,例如 PostGISpgvector 从未在 PGXN 上发布。

此外,扩展很难安装,尤其是对于新手来说。 YumApt 存储库提供了数百个易于安装的扩展,但很难找到它们,因为它们没有在 PGXN 或网络上的其他注册表中列出。

2023 年出现了一批新的参与者,包括 trunkdbdev,以及(在 2024 年初),pgxman。这些扩展注册表更关注易用性,而不是分发:虽然 PGXN 在源代码分发方面做得很好,但这些服务旨在通过为选定的操作系统和架构构建并提供可下载的二进制文件来极大地简化安装pgxn 客户端 需要完整的编译器工具链和 Postgres 开发功能来构建 PGXS 扩展,而这些注册表客户端只需下载并安装二进制包(或者,对于 dbdev 来说,TLE)直接。

这有助于在有限数量的平台上,为少数扩展从发现到安装再到实验的周期缩短了时间。但很明显,人们渴望有一个权威的、可搜索的索引,其中包含所有支持二进制安装的扩展。

重新思考

2024 年 1 月,Theory 开始在 Tembo 工作,他的任务是在越来越需要权威来源和二进制分发的背景下,重新思考 PGXN 的作用和架构。直接的结果就是这个代号为“PGXN v2”的项目。

随着设计、计划和实施的进行,本页面将定期更新链接和更新。这些工作跨越各种博客文章、GitHub 存储库、Gists、邮件列表、Slacks、Discourses 和会议环节进行。在这里,我们将尽力将它们全部链接起来,作为一种中心索引和讨论和反馈的出发点。

状态

Diagram of the extension distribution ecosystem vision, featuring “Root Registry” in the center and bidirectional lines to four of the surrounding nodes: “Web UX”, “Client”, “Packaging”, and “Interactions”. The “Packaging” and “Interactions” boxes also have a bi-directional arrow between them, while the fifth box, “Stats & Reports”, has a bi--directional arrow pointing to “Interactions” and another arrow pointing to “Root Registry”.
未来拟议的扩展分发架构的六个逻辑服务的顶层图。 根注册表位于中心,为其他服务提供 API,以便它们自己使用。这些服务的受信实例通过交互服务提交有关扩展的额外数据,以增强和丰富服务,更好地告知和取悦用户。

我们目前正在寻求对 PGXN v2 架构 的审查、反馈、问题和评论,该文档定义了要提供的服务以及运行它们的架构,以及指导项目规划和决策的战略愿景。

来自引言

本文件概述了构建扩展分发、发现和打包工具和服务的项目,以推动 Postgres 扩展生态系统的增长、可访问性和实用性。以整个 Postgres 社区为目标受众,它定义了要提供的服务以及运行它们的架构,以及指导项目规划和决策的战略愿景。

为了战略性思考和务实地计划,本文件描述了前者以实现后者。因此,它必然是高层次的;细节、范围和计划将在更多以项目为中心的文档中呈现。

请记住,本文件概述了一个雄心勃勃的长期战略。如果你认为这里的东西太多了,我们过度思考和过度设计了系统,请放心,项目执行将从根本上是渐进的和务实的。本文件是项目的指导灯塔,并且随着开发的进行和新问题出现而可能会发生变化。

索引

RFCs

二进制分发格式
此 RFC 指定了 PGXN 包的二进制分发格式,也称为 trunk 格式。灵感来自 Python wheel 格式Trunk

设计文档

扩展生态系统:工作和工具
当前 Postgres 扩展生态系统的挑战以及人们对探索新解决方案的兴趣和精力表明,现在是重新审视整个想法的时候了。我们首先对扩展打包和分发需要完成的工作进行调查,然后列出预计将使其成为现实的工具和服务。
PGXN v2 架构
概述了构建扩展分发、发现和打包工具和服务的项目,以推动 Postgres 扩展生态系统的增长、可访问性和实用性。以整个 Postgres 社区为目标受众,它定义了要提供的服务以及运行它们的架构,以及指导项目规划和决策的战略愿景。
服务配置
对雄心勃勃的未来 PGXN 服务和架构的总结,以及对现有服务的检查,以及它们将如何逐步重构或替换以适应更新的平台。

博客文章

PGXN 挑战
关于 PGXN 在未来理想的 PostgreSQL 扩展生态系统中的作用所面临的挑战的一些想法。
思考去中心化的扩展发布
Go 包生态系统使用分布式发布来发布模块,无需身份验证或上传。我们是否可以对 Postgres 扩展做类似的事情?
扩展生态系统需要完成的工作
当前 Postgres 扩展生态系统的挑战以及人们对探索新解决方案的兴趣和精力表明,现在是重新审视整个想法的时候了。我们首先对扩展打包和分发需要完成的工作进行调查。
扩展版本控制的历史和未来
应该使用什么版本控制标准进行 Postgres 扩展分发?来自 PostgreSQL 和 PGXN 的一些背景信息,对当今版本控制标准领域的调查,以及一个建议。
RFC:扩展元数据类型
思考 PostgreSQL 扩展元数据的用例,并认识到它们需要的信息类型。
Postgres 扩展发现和分发的重大发展
我们希望听到来自所有人的反馈和想法,无论大小,使扩展体验对用户和开发人员来说都更好。
扩展注册表命名空间 RFC
对 Postgres 扩展打包和分发的一个额外的名称唯一性级别提案,基于 URI。
RFC:PGXN 元数据草稿
请求对 Postgres 扩展打包、分发和交付的新元数据标准草稿的意见,该标准建立在 PGXN 元数据规范 的基础上,以解决 12 年后的不足之处和新出现的用例。
PGXN v2:Go 还是 Rust?
我们应该使用哪种编程语言(或语言)来构建新的 PGXN 服务和工具,以及改造现有的工具:Rust 还是 Go?[投票已结束。]
Álvaro Hernández:为什么 Postgres 扩展应该打包并作为 OCI 镜像分发
这都是关于不重新发明轮子,以及利用围绕 OCI 的生态系统。构建、打包和分发扩展中的许多问题(解决方案)已经由 OCI 解决:围绕 OCI 的整个工具生态系统提供了工具、基础设施和通用知识方面的额外优势。

演示

演示:PGXN 架构简介 (2024-02-01)
Theory 为 Tembo 团队制作的关于 PGXN 架构的演示视频。

生态系统峰会

2024 年扩展生态系统峰会 是在 PGConf.dev 2024 举行的面对面活动。请参阅 报告 以了解讨论主题的总结,以及 峰会笔记 以获取所有详细信息。

峰会之前进行了一系列虚拟小型演讲和社区讨论,称为 小型峰会

David Wheeler 谈扩展生态系统的现状 (2024-03-06)
来自第一个 扩展生态系统小型峰会 的视频、幻灯片和笔记,涵盖了 PostgreSQL 可扩展性和 PGXN 的历史和未来。
Ian Stanton 谈构建 Trunk (2024-03-20)
来自第二个 扩展生态系统小型峰会 的视频、幻灯片和文字记录,涵盖了构建 trunk 二进制扩展注册表的动机、设计、架构和经验教训。
Devrim Gündüz 谈 RPM 化扩展 (2024-04-03)
来自第三个 扩展生态系统小型峰会 的视频、幻灯片和文字记录,涵盖了 社区 Yum 存储库 的历史、设计和维护,以及通过 Yum、Apt 等分发扩展的影响。
Jonathan Katz 谈受信任的语言扩展 (2024-04-07)
来自第四个 扩展生态系统小型峰会 的视频、幻灯片和文字记录,涵盖了受信任的语言扩展(也称为 [TLE https://github.com/aws/pg_tle])的愿景和细节。
Yurii Rashkovskii 谈通用可构建扩展 (2024-05-01)
来自第五届 扩展生态系统迷你峰会 的视频、幻灯片和文字记录,其中 Yurii Rashkovskii 描述了一个概念验证,该验证展示了如何构建扩展,以及在 Postgres C 源代码在次要版本中发生更改时可能遇到的潜在挑战。
社区组织峰会主题 (2024-04-17)
第六届也是最后一届扩展生态系统迷你峰会的视频、幻灯片和粗略文字记录,其中我们回顾了在 PGConf.dev 的线下峰会上可能讨论的主题,并讨论了如何组织它。