jayzhan211 commented on issue #7142:
URL:
https://github.com/apache/arrow-datafusion/issues/7142#issuecomment-1817763196
```text
D select array[[[1]], null, [null], [[3, 4]]];
┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ (ARRAY[main.list_value(main.list_value(1)), NULL, main.list_value(NULL),
main.list_value(main.list_value(3, 4))]) │
│ int32[][][]
│
├───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ [[[1]], NULL, [NULL], [[3, 4]]]
│
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
```
@alamb Do we have to deal with nested list like duckdb? If we naively
convert null to i32. We got `list(list(i64)), i32, list(i32), list(list(i64))`
It is hard to tell whether it is `null cases` or invalid unaligned dimension
inputs.
If we just find the highest dimension one and convert null to it. We got
`list(list(i64)), list(list(i32)), list(list(i32)), list(list(i64))`, then we
lost the information for `dimension of null`, so we can not come out a result
like `null, [null]` as duckdb does.
I found current approach is hard to deal with if we consider dimension.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]