SQLGlot中Select语句构建的正确方式

在SQL解析和生成工具SQLGlot中，构建SELECT语句时存在两种看似相似但实际上差异显著的方式。本文将深入探讨这两种方式的区别，并解释为什么其中一种方式会失效。

问题现象

当开发者尝试构建SELECT语句时，可能会遇到以下两种写法：

# 方式1：使用from_参数
q1 = exp.Select(
    expressions=[exp.Star()],
    from_=exp.From(this=values_exp)
)

# 方式2：使用from_方法
q2 = exp.Select(
    expressions=[exp.Star()],
).from_(exp.From(this=values_exp))

表面上看，这两种方式应该产生相同的结果，但实际上第一种方式生成的SQL缺少FROM子句，而第二种方式则能正确生成完整的SQL语句。

根本原因

这个问题的根源在于SQLGlot的AST(抽象语法树)节点结构设计。在SQLGlot的内部实现中：

1. SELECT语句的AST节点实际使用的是from属性，而不是from_
2. 当使用构造函数的from_参数时，这个参数不会被正确映射到AST节点的from属性
3. 而from_()方法内部会正确处理这个映射关系，将值赋给正确的AST节点属性

最佳实践

基于这个发现，我们得出以下最佳实践建议：

1. 优先使用链式方法调用：如.from_()、.select()等方法，这些方法内部会正确处理AST节点的构建
2. 避免直接通过构造函数参数构建复杂AST：特别是对于SQL关键字与Python关键字冲突的情况(如from)
3. 谨慎使用代码补全建议：某些AI辅助工具可能会给出不准确的构造方式

深入理解

SQLGlot的这种设计实际上反映了AST构建的两种模式：

1. 声明式构建：通过构造函数一次性指定所有属性
2. 命令式构建：通过方法链逐步构建AST

在大多数情况下，方法链的方式更为可靠，因为：

• 方法内部可以包含额外的验证和处理逻辑
• 可以更清晰地表达构建过程
• 避免了Python关键字与SQL关键字的冲突问题

总结

在SQLGlot中构建SELECT语句时，推荐使用.from_()方法而非构造函数的from_参数。这不仅解决了当前的问题，也是更符合SQLGlot设计理念的做法。理解AST构建的这两种模式差异，有助于开发者更有效地使用SQLGlot进行SQL解析和生成。