PostgreSQL 社区风格开发总结
PostgreSQL 项目历经二十多年，其软件开发准则和要求以严格著称，本文的目的是为了介绍一些PG社区的开发hints。也算是初入PG社区的一些随笔，好的软件开发不仅包含代码礼仪，还应该包含优雅简洁的邮件/交流礼仪。事实上，下面列出的一些礼仪不仅是在PG社区、也是其他开源社区应该学习和了解的典型范例，更是在科技行业使用邮件、Github、在任意平台讨论技术和代码的优秀准则。
先理解社区价值观：
PostgreSQL 代码库是 20+ 年积累、还要继续用很多年，因此对设计、兼容性、可维护性要求更严格；如果想要参与不要着急修改代码或者文档，并且也从简单改动开始、逐步积累贡献经验。先达成共识：先接口/行为，后实现细节，不要闭门造车，要先在社区层面把新行为定义清楚并获得认同。
接口层要想清楚：用户如何使用、语法是什么、语义/行为精确定义、是否有向后兼容问题，并且要在这个粒度上先 buy-in。
再讨论实现：会改哪些子系统/哪些 C 文件、与其它特性怎么交互、错误处理、是否涉及系统表、dump/restore（必要时要修 pg_dump）、psql 是否需要改。
代码风格很重要：格式、命名、与上下文一致
- 格式：4 空格缩进、BSD brace style，pgindent 是有帮助但并不万能，代码合入的关键之一是模仿周边代码风格。
- 命名：可以 camel / snake，但避免风格不统一；
- 融入代码：不要用 #ifdef 把改动包起来；注释是为澄清而不是标记代码是谁的；不要在代码里署名。
注释与 C 语言规范
好命名能减少注释需求，但任何可能不清楚的地方要注释；用 ANSI C（C89）而不是 C99；不要 //；变量声明放在代码块开头。测试与文档是接受补丁的关键门槛
测试：现有回归测试是否全过？行为改变是否是“有意的”？是否需要新增回归测试？initdb 是否正常？是否存在不可移植构造。
文档：新增命令/选项要更新 reference pages；影响管理员要写到管理文档；新增函数要补函数文档；已有章节是否需要同步修改。
沟通与协作：
初始邮件结构建议包含：高层总结、为什么要做（问题/收益/影响用户/为什么现在）、为什么这样设计（区别于以往尝试/设计解释/为什么不用其它方案/哪些部分没做）、以及 call to action（TODO、开放问题、还需要做什么、当前遇到的 failing / issue）。
要有轻重缓急；尽量把相关老贡献者/相关用户拉进来（CC）；参与同领域线程。
对 review 的响应方式：
回答 reviewer 的问题；发新版本时逐点 inline回应；风格问题保持灵活；同类问题要“一次性全改”；必要时可以另开新线程。让代码跑起来：使用示例 + 基准测试（可复现）
基准测试目的：证明性能提升或至少没有回退。
基准测试原则：简单就好（\timing on 也可以）、优先 pgbench、避免 bash 脚本和附件、减少干扰变量、缩短运行时间、确保可复现。
报告应说明：准备步骤（prewarm/restart/initdb）、配置（GUC/table options）、schema & data、机器规格/系统设置。
结果呈现：不要塞过多数据；TPS 不是唯一指标，也可以给 plan diff、perf 摘要、P99 latency、内存、进程 IO 等。
测试：回归测试要“最小、快、稳”，必要时提供复现脚本
回归测试强调 minimal/fast/reliable，并涉及 core SQL suite 及其它套件；当加测试困难时，也可以用 debug-only 验证来增强信心并保护未来开发者。让 patch 可提交：核心是拆分 commits
让每个 commit 都能工作；不要大杂烩/巨型 commit；commit message 要解释每一行改动的目的；refactor 必须有动机；功能改动要一眼看出来；注释和 commit message 要把风险与需要采取的动作说清楚。分离“形式 vs 功能”、单问题提交、别分散 reviewer 注意力；必要时先 rearrange 再 relocate；新 API 单独一个 commit。
PostgreSQL 社区风格开发总结
