C++ 兼容性
提案
有时人们希望在 PostgreSQL 后端环境中调用 C++ 代码......例如，在用户定义函数、触发器、访问方法中。有时 C++ 代码也需要回调到 PostgreSQL 的 C 函数，比如 SPI 接口。许多有用的软件包和库都是用 C++ 编写的。
附带的 4 个补丁旨在为 C++ 爱好者提供最小的支持级别，以便轻松地编译和链接到 PostgreSQL 后端。没有提供新的接口或包装器。目标仅仅是使后端成为开发涉及 C++ 的扩展的更友好的地方，对现有的 C 代码影响最小。
提出的更改被分为 4 个补丁，希望每个补丁都简单易懂。可以独立地审查和讨论它们，我希望其中一些或全部被认为足够良性，可以被纳入到 8.5 或更早的版本中。
补丁概述
这些补丁将在下面详细描述。它们是：
- c++reserved -- 更改了一些碰巧是 C++ 保留字的字段和参数名称
- c++bookends -- 在一些头文件中添加 C 链接声明
- c++configure -- 将 C++ 支持添加到 'configure'、'make' 和 'pg_config' 中。一个新的配置选项 --enable-cplusplus 将 C++ 运行时库链接到 postgres 后端。
- c++exception -- 将未捕获的 C++ 异常转换为 PostgreSQL elog(FATAL) 错误
争议
我回溯到 2005 年的档案，只发现了这个涵盖类似内容的帖子
- SPI-header-files safe for C++-compiler (2007 年 6 月)
该补丁看起来与我的前两个补丁（c++reserved 和 c++bookends）大致相同。在我看来，该帖子中提出的反对意见显得牵强，更多的是发泄情绪，而不是提供有意义的论据。“嘿，你们这些孩子，别在我家草坪上闹！” 协商过程的结论没有在该帖子里写下来；但显然，赞成意见没有说服力：最终，该补丁没有被应用。
最主要的反对意见似乎是，不应该在没有自动执行机制来保证将来永远不会出现新情况的情况下尝试缓解现有的保留字问题。
但我们能否将 (1) 今天阻止 C++ 编译的实际标识符，与 (2) 将来有人可能提交的假设代码这两个问题分开？ 第一个问题是迫在眉睫的；第二个问题只有在假设标识符通过测试阶段进入发布版本时才会造成麻烦。
该帖子的第 21 帖，由 Tom Lane 提出，建议对不符合 C++ 编译标准的头文件进行自动检查，并强调了构建系统缺乏 C++ 支持所造成的实际困难。我的第三个补丁 - c++configure - 开始着手解决用可移植的方式构建 C++ 代码的需求，与我们构建 C 代码的方式兼容。
将整个 PostgreSQL 转换为 C++ 的想法被提了出来。这样做几乎没有好处，却要付出巨大的枯燥工作，因此我建议不要这样做。除非有明显的好处，否则我不想重做旧的东西。我的提案旨在使 C++ 成为在 PostgreSQL 中添加 *新* 功能的实用选择。
一个非常有趣的话题是 C++ 异常与 PostgreSQL 后端基于 setjmp/longjmp 的错误处理之间的关系。我的第四个补丁 - c++exception - 添加了一个后备机制，以限制从后端中的任何地方抛出但未捕获的 C++ 异常造成的损害。该补丁将未捕获的异常转换为 PostgreSQL FATAL 错误，以便进程可以清理自身并报告其故障，而不是仅仅默默地消失。如果 C++ 代码没有捕获其异常，那就是编程错误，类似于段错误或空指针解除引用，应该终止程序。
这四个补丁并不意味着为 C++ 程序员创造一个舒适的天堂。还可以做更多的事情：可以提供更复杂的错误处理；可以将 new/delete 连接到 palloc/pfree；可以编写模板和类库。但是，如果我们给他们一个机会，C++ 程序员可以自己完成这些事情：只要消除障碍（主要是保留字），并使其易于编译和链接即可。
早期关于 C++ 问题的讨论
- 存储过程中的 STL 问题 (2005 年 10 月)
- C++ -> C : 使用 PostgreSQL 将 WHERE 子句转换为规范形式的模块 (2006 年 1 月)
- PG 扩展：必须静态链接吗？ (2006 年 3 月)
- 用 C++ 编写触发器 (2007 年 2 月)
