Pql，一种编译为 SQL 的流水线查询语言
一种名为 Pql 的新流水线查询语言，受 Kusto 和 Splunk 的 SPL 等工具启发，旨在通过编译为标准 SQL 执行，为用户提供比 SQL 更易读、面向安全场景的替代方案。评论者就这种额外抽象是否真的优于成熟方案（如 PRQL、类 LINQ 库，或直接编写 SQL）展开争论，并提出了性能、缺失功能（例如窗口函数）以及维护另一种 DSL 的长期成本等担忧。也有人认为，SQL 的复杂性、不同方言之间的不一致，以及对空值等概念的笨拙处理，足以证明像 Pql 这样的实验是有价值的，尤其是在它能与现有数据库和工具链良好集成的情况下。
动机与目标用户
- 设计为一种小型的流水线语言，编译为 SQL，深受 Kusto / SPL 风格查询语言启发。
- 主要面向不喜欢 SQL、且已经习惯 KQL、Splunk SPL、Sumo 等工具的安全工程师和分析师。
- 被视为一种在通用 SQL 引擎之上获得类似 KQL 的易用性，并减少对专有日志查询 DSL 供应商锁定的方法。
与 SQL 的比较
- 支持者喜欢其线性、从左到右的流水线风格以及更短、类似 KQL 的语法。
- 批评者认为示例是在把“漂亮”的 Pql 与故意写得很绕的 SQL 做对比；惯用 SQL 也可以几乎同样简单。
- 有人认为 SQL 的稳定性和普及性胜过再学习一种 DSL 的好处；也有人认为 SQL 从根本上就很别扭，甚至“很糟糕”。
与其他查询语言的关系（PRQL、LINQ 等）
- 与 PRQL 的对比很强烈：两者都是编译为 SQL、采用流水线语法。
- 有人质疑为什么不直接复用 PRQL；回复提到目标受众不同、语法偏好不同，以及希望采用纯 Go 实现。
- 也有人将其与 LINQ、dbplyr、CoffeeScript/TypeScript 之于 JS，以及多个类似的“后 SQL”项目（TQL、XTQL、Preql）进行比较。
性能与查询规划
- 有人担心 Pql 生成的基于 CTE 的输出（WITH 子查询）可能很慢，或迫使糟糕的连接顺序。
- 也有人指出现代引擎常常会内联 CTE，因此简单场景不应有问题；但对复杂查询的影响尚不明确。
- 普遍怀疑另一层抽象能否比直接写 SQL“更高效”，除非只是提高开发者生产力。
实现选择（Go、绑定、解析）
- 围绕使用 Go 还是封装基于 Rust 的 PRQL 展开争论：Go + C 绑定可行，但有人认为 Go 的 FFI 很笨拙；也有人说现在的开销已经很小。
- 作者手写了一个解析器；其他评论者分享了自己构建递归下降解析器的经验，认为这既有教育意义又很灵活。
空值处理与语义
- Pql 由于只是转译，因此继承了 SQL 的 NULL 行为；它并没有修复三值逻辑问题。
- 有人认为更好的设计应使用 Option/Maybe 类型，但那将需要一种根本不同的语言，而不仅仅是 SQL 前端。
LLM 与 DSL
- 有几位评论者提到，LLM 到 SQL 的工具很有前景，但不可靠：用于起草第一版可以，关键正确性场景则不行。
- 一些人认为 Pql 是一种更确定性的桥梁：对某些用户来说比 SQL 更容易，但仍然明确且可检查。
局限性与怀疑
- 评论者指出缺少高级 SQL 特性（窗口函数、聚合过滤、特定数据类型函数、参数）。
- 有人担心增加复杂性、在查询规划器之上再加一层“引擎盖”，以及又一种寿命短暂的查询语言。
- 也有人对在标准 SQL 后端上实现类似 KQL 的易用性表示兴奋，并欢迎在这一领域进行更多实验。