PLPSM
来自 PostgreSQL 维基
跳转到导航跳转到搜索我开始着手为 PostgreSQL 实现 PSM 语言。这是我对该主题的第二次尝试。我基于 PLpgSQL 解释器编写了 PLpgPSM 解释器。几年后，我决定这不是一个好的方法，于是从头开始。
- PLpgSQL 是一种非常成熟的语言（解释器）
- 代码相对复杂，但不稳定，
- 它是一个解释器，对 SQL 代码的检查非常懒惰，
- 代码在速度方面几乎没有优化，
- 代码很旧 - 出于向后兼容性的原因，一些已知的技巧没有被全部使用。
- PLpgSQL 类型系统相对复杂 - 它使用标量、行和记录。
将一种类似于 PLpgSQL 的代码复杂度的新语言移植到核心中的可能性微乎其微。但在核心之外，维护一段复杂的代码是比较困难的工作，因此 PLpgSQL 并不是新语言的理想基础。这就是我从零开始的原因。在接下来的几年里，目标不是达到与 PLpgSQL 相同的性能，而是良好的可维护性、可读性和可扩展性。与 PL/pgSQL 不同，PSM 语言需要在编译时检查查询 - 与语句 FOR 相关的自动变量是从查询的结果中推断出来的。因此，这些类似的语言需要稍微不同的设计。PL/pgSQL 的另一个问题是它比必要的更加动态。多年来，动态 SQL 一直是一个恶棍。因此，目标是消除动态 SQL 的使用。您可以在从不存在的表中读取（在启动执行时间）的函数中使用查询，您可以调用不存在的函数。这些功能在 PSM 中不可用，因为集成查询在早期进行了检查。现在，动态 SQL 不会构成风险（使用 USAGE 子句），因此没有理由让编译器变得更加复杂。此外，SQL 中的错误在早期就被发现了。
关于 SPI 应该改变的点
- 一些表达式解析器和执行器支持，
- 确保结果类型和 typmods 的可能性，
- 激活隐式转换的可能性，
- 从游标获取到指定类型的目标的可能性，
- 一些对复合类型更好的工作。
计划
- psm0 .. 简单但具有完整功能的编译器
- psm1 .. 用户友好的错误消息和诊断 + 回归测试
- psm2 .. 最大可能的性能
- plpsm .. 目标实现
在 psm0 和 plpsm 之间，实现的功能将不会改变 - 只会修复错误。已实现功能的完整列表在 test.sql 文件中的示例中指定。
