You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SQL: Resolve attributes recursively for improved subquery support (#69765) (#70322)
Previously we did not resolve the attributes recursively which meant that if a field or expression was re-aliased multiple times (through multiple levels of subqueries), the aliases were only resolved one level down. This led to failed query translation because `ReferenceAttribute`s were pointing to non-existing attributes during query translation.
For example the query
```sql
SELECT i AS j FROM ( SELECT int AS i FROM test) ORDER BY j
```
failed during translation because the `OrderBy` resolved the `j` ReferenceAttribute to another `i` ReferenceAttribute that was later removed by an Optimization:
```
OrderBy[[Order[j{r}#4,ASC,LAST]]] ! OrderBy[[Order[i{r}#2,ASC,LAST]]]
\_Project[[j]] = \_Project[[j]]
\_Project[[i]] ! \_EsRelation[test][date{f}#6, some{f}#7, some.string{f}#8, some.string..]
\_EsRelation[test][date{f}#6, some{f}#7, some.string{f}#8, some.string..] !
```
By resolving the `Attributes` recursively both `j{r}` and `i{r}` will resolve to `test.int{f}` above:
```
OrderBy[[Order[test.int{f}#22,ASC,LAST]]] = OrderBy[[Order[test.int{f}#22,ASC,LAST]]]
\_Project[[j]] = \_Project[[j]]
\_Project[[i]] ! \_EsRelation[test][date{f}#6, some{f}#7, some.string{f}#8, some.string..]
\_EsRelation[test][date{f}#6, some{f}#7, some.string{f}#8, some.string..] !
```
The scope of recursive resolution depends on how the `AttributeMap` is constructed and populated.
Fixes#67237
0 commit comments