SQLGlot项目中的Spark到DuckDB数组聚合转换问题分析

在SQLGlot这个SQL解析和转换工具的最新版本(25.19.0)中，出现了一个关于Spark SQL到DuckDB SQL转换的特定问题。这个问题主要涉及array_agg函数与distinct struct结构的组合使用场景。

问题现象

当从Spark SQL方言转换到DuckDB方言时，包含array_agg(distinct struct(...))结构的查询会被转换为包含FILTER子句的形式。例如：

原始Spark SQL:

array_agg(distinct struct(name, min_creation_time as timestamp))

转换后的DuckDB SQL:

ARRAY_AGG(DISTINCT {'name': name, 'timestamp': min_creation_time}) 
FILTER(WHERE {'name': name, 'timestamp': min_creation_time} IS NOT NULL)

这种转换在DuckDB中执行时会抛出"INTERNAL Error: Attempted to dereference shared_ptr that is NULL!"错误。

技术背景

SQLGlot在25.19.0版本中引入了一个变更，目的是为ARRAY_AGG函数添加NULL值排除的转换逻辑。这个变更原本是为了处理可能包含NULL值的列情况，确保聚合结果中不包含NULL元素。

然而，当这个逻辑应用到结构体(struct)构造表达式时，特别是与DISTINCT关键字组合使用时，就触发了DuckDB内部的一个边界条件错误。

问题本质

深入分析这个问题，我们可以发现几个关键点：

1. 结构体构造的特殊性：在DuckDB中，结构体构造表达式{'name': name, 'timestamp': ...}本身几乎不可能为NULL，除非构造参数中有NULL值。

2. FILTER子句的冗余性：对于这种确定性的结构体构造，添加FILTER子句检查是否为NULL实际上是不必要的，甚至可能干扰查询优化器的正常工作。

3. DuckDB的内部处理：错误信息表明DuckDB在处理这种特定形式的查询时，内部指针管理出现了问题，这应该被视为DuckDB的一个边界条件bug。

解决方案

从SQLGlot的角度，最合理的解决方案是：

1. 识别结构体构造场景：在转换逻辑中，需要特别识别struct或结构体构造表达式。

2. 条件性添加FILTER：只有当聚合表达式可能产生NULL值(如直接引用可能为NULL的列)时，才添加FILTER子句。

3. 优化转换逻辑：对于确定性的表达式(如结构体构造、字面量等)，可以安全地省略FILTER子句。

版本兼容性

这个问题在SQLGlot 25.18.0及更早版本中不存在，因为那时还没有引入自动添加FILTER子句的逻辑。回退到这些版本可以作为一种临时解决方案，但长期来看，修复转换逻辑才是更合理的做法。

最佳实践建议

对于使用SQLGlot进行Spark到DuckDB转换的开发人员，建议：

1. 检查复杂聚合查询：特别注意包含array_agg和结构体的查询转换结果。

2. 版本控制：如果遇到类似问题，可以考虑暂时使用25.18.0版本。

3. 简化查询结构：在可能的情况下，将复杂聚合拆分为更简单的表达式。

4. 监控转换结果：对关键查询的转换结果进行验证测试，确保生成的SQL在所有目标数据库上都能正确执行。

这个问题展示了SQL方言转换工具在实际应用中可能遇到的复杂情况，也提醒我们在处理聚合函数和复杂数据类型时需要格外谨慎。