Show HN：PostgreSQL 中的 PRQL

原文 ↗ Hacker News 讨论 ↗

一个新的 PostgreSQL 扩展把 PRQL——一种可编译为 SQL 的管道式查询语言——带入数据库，引发了关于在 SQL 已经无处不在且功能强大的情况下，高层 DSL 是否值得采用的争论。支持者认为，PRQL 的函数式、可组合语法、更强的自动补全潜力，以及面对复杂分析模式时的简洁性，都能改善开发者体验，尤其对非专家更友好。质疑者则反驳说，它只是增加了一层抽象，可能带来性能误解，并且在现有 SQL 工具、培训以及跨数据库差异的背景下，采用上存在结构性障碍。

PRQL 是什么以及它如何工作

  • PRQL 被描述为一种更高层、更规整的查询语言，可编译为 SQL。
  • 它不是 ORM，也不会添加超出 SQL 的能力；它在很大程度上只是带有函数式 / 管道风格的语法糖。
  • 这个 Postgres 扩展基于 pgrx 构建，目前只支持 Mac/Linux，因为 pgrx 尚不支持 Windows。

动机：开发者体验、可读性、自动补全

  • 支持者强调开发者体验：更快表达分析型查询、更函数式的思维，以及管道化的“from-first”语法。
  • 自动补全和类型检查是关键卖点；SQL 中 SELECT 在前、FROM 在后的顺序被认为对工具支持来说很别扭。
  • 有些人认为它是以变换/关系代数的方式思考问题的更清晰途径，尤其适合复杂分析和 EDA。

质疑：SQL 已经足够 / 抽象层的代价

  • 许多人认为 SQL 功能丰富、无处不在、文档完备且到处都有支持；再加一层会增加复杂度、培训成本以及潜在混淆。
  • 有些人觉得 PRQL 并没有解决 SQL 最难的部分：用集合/关系的方式思考。它主要只是整理了语法。
  • 另一个抽象层可能会隐藏性能影响，尤其是在 join/filter/order 的选择上。

示例争论：“每张专辑最长的曲目”

  • 一个核心争论是：PRQL 对“每组取前 N 项”这类查询是否实质上更简单？
  • 讨论串展示了多种 SQL 解法（Postgres 特有的 DISTINCT ON、窗口函数、QUALIFY、子查询），并指出这种模式并不简单，但大家都很熟悉。
  • 有些人承认自己记不住标准 SQL 写法；另一些人则说任何稍有经验的 SQL 用户都能写出来。

可组合性、调试与工具

  • 有人批评 SQL 缺乏可组合性；也有人反驳说 CTE、视图和函数已经提供了组合能力。
  • 存储过程/函数的可调试性普遍被认为很痛苦。
  • 讨论中还涉及函数内联、易变性（STABLE/IMMUTABLE）以及 Postgres 中令人意外的规划器行为。

采用与生态系统方面的担忧

  • 组织通常更看重可靠性和共享知识，而不是渐进式的语法改进。
  • 生成 SQL 的 LLM 减轻了冗长 SQL 带来的痛点，也可能削弱采用类似 PRQL 的层的动力。
  • 与数据库无关这一点也受到质疑；许多人认为针对特定引擎（例如 Postgres、Oracle）进行优化更重要。

相关 DSL 与未来方向

  • 讨论将其与 Ecto、EdgeQL、jq、awk、Kusto、Malloy，以及其他构建在 SQL 之上的 DSL / 语义层进行比较。
  • 有些人认为 Postgres 作为通过扩展承载多种嵌入式 DSL 的宿主很有前景。

HN 元话题：样式与 UX

  • 另一个子讨论解释了 HN 对文本帖子的灰色文本以及被踩评论的处理是有意的弱化显示，还提到绿色用户名和踩票阈值。