SQLGlot中Trino到BigQuery的窗口函数转换问题分析

问题背景

在使用SQLGlot进行SQL方言转换时，我们发现从Trino到BigQuery的窗口函数转换存在一个特殊问题。具体表现为当使用OVER (ORDER BY ...)语法时，SQLGlot会自动添加NULLS LAST修饰符，而这在BigQuery中会导致语法错误。

问题重现

通过以下Python代码可以重现该问题：

import sqlglot

sql = """
WITH t1 as (
  select 1 f1, 2 f2 union all select 2 f1, 4 f2 union all select 3 f1, 6 f2
)
select sum(f1) over (order by f2) from t1;
"""
result = sqlglot.transpile(sql, read="trino", write="bigquery")[0]
print(result)

转换后的SQL会在ORDER BY子句中自动添加NULLS LAST，导致BigQuery报错："NULLS LAST not supported with ascending sort order in RANGE clauses of analytic functions"。

问题本质

这个问题源于Trino和BigQuery在窗口函数排序行为上的差异：

1. Trino默认行为：在Trino中，当使用ORDER BY进行窗口排序时，默认会将NULL值放在最后（相当于隐式的NULLS LAST）

2. BigQuery限制：BigQuery明确不支持在窗口函数的RANGE子句中使用NULLS LAST修饰符，特别是对于升序排序

3. SQLGlot转换逻辑：当指定read="trino"时，SQLGlot会显式添加NULLS LAST以保持与Trino相同的行为语义，但这与BigQuery的语法限制冲突

解决方案比较

测试发现两种解决方案：

1. 不指定输入方言：当不指定read参数时，SQLGlot不会添加NULLS LAST修饰符，转换后的SQL在BigQuery中可以正常工作

result = sqlglot.transpile(sql, read=None, write="bigquery")[0]

2. 手动移除修饰符：可以在转换后手动移除NULLS LAST修饰符

技术建议

对于需要从Trino迁移到BigQuery的项目，建议：

1. 评估是否真的需要显式的NULL排序行为
2. 如果不需要精确的NULL排序语义，可以不指定输入方言
3. 如果需要保持NULL排序行为，可能需要重写查询逻辑，使用CASE表达式等替代方案

总结

SQL方言转换工具虽然强大，但在处理特定语法特性时仍需谨慎。本例展示了Trino和BigQuery在窗口函数NULL值处理上的差异，以及SQLGlot在保持语义准确性时可能带来的兼容性问题。开发者在进行SQL迁移时应充分了解目标数据库的限制，必要时进行手动调整。