DataFusion 项目中 UNNEST 操作符的 SQL 转换问题分析

在 Apache DataFusion 项目中，开发者发现了一个关于 UNNEST 操作符在 SQL 转换过程中出现的错误行为。这个问题涉及到 SQL 查询计划到 SQL 语句的反向转换过程，特别是在处理包含多个 UNNEST 操作的查询时。

UNNEST 是一个常见的 SQL 操作符，用于将数组展开为多行。在 DataFusion 中，当执行从逻辑计划转换回 SQL 语句时，系统会错误地合并不同的 UNNEST 操作，导致生成的 SQL 语句与原始查询语义不符。

具体表现为，当查询中包含多个 UNNEST 操作时，如：

SELECT unnest([1, 2, 3, 4]) from unnest([1, 2, 3])

转换后的 SQL 会错误地变为：

SELECT * FROM UNNEST([1, 2, 3])

这显然改变了查询的原始意图。

问题的根源在于 DataFusion 的 SQL 反解析器(unparser)在处理 UNNEST 操作时的逻辑。当启用 with_unnest_as_table_factor 选项时，系统会尝试将 UNNEST 保留在 FROM 子句中，但没有正确处理多个 UNNEST 操作同时存在的情况。

开发者提出了几种解决方案思路：

1. 在 UNNEST 占位符中添加位置信息，类似于现有的深度信息，以区分不同位置的 UNNEST 操作
2. 对于只允许 UNNEST 作为表因子(table factor)的特定方言(如 BigQuery)，可以在遇到这种情况时直接抛出错误

经过讨论，开发者倾向于采用第一种方案，通过增强 UNNEST 占位符的信息来准确还原查询结构。这种方案虽然不够完美，但在当前架构下是最可行的解决方案。

这个问题反映了 SQL 反解析过程中处理复杂操作符时的挑战，特别是在需要保持查询语义不变的情况下。对于 DataFusion 这样的查询引擎来说，确保查询计划与 SQL 语句之间的双向准确转换至关重要，特别是在支持多种 SQL 方言的场景下。

开发者还注意到，这个问题与项目中正在进行的其他改进工作相关，特别是关于移除双重别名(Alias)的工作。这提醒我们在进行系统重构时需要全面考虑各种边缘情况，确保功能的完整性和一致性。