milevin commented on PR #5748:
URL:
https://github.com/apache/arrow-datafusion/pull/5748#issuecomment-1485496016
Consider the above query. After `plan_selection` is finished in `select.rs`,
the assigned column properties are as follows:
```
DFField {
qualifier: Some(
Bare {
table: "t1",
},
),
field: Field {
name: "col1",
data_type: Int64,
nullable: false,
dict_id: 0,
dict_is_ordered: false,
metadata: {},
},
},
DFField {
qualifier: Some(
Bare {
table: "t1",
},
),
field: Field {
name: "col2",
data_type: Utf8,
nullable: false,
dict_id: 0,
dict_is_ordered: false,
metadata: {},
},
},
DFField {
qualifier: Some(
Bare {
table: "t2",
},
),
field: Field {
name: "col3",
data_type: Int64,
nullable: false,
dict_id: 0,
dict_is_ordered: false,
metadata: {},
},
},
DFField {
qualifier: Some(
Bare {
table: "t2",
},
),
field: Field {
name: "col4",
data_type: Utf8,
nullable: false,
dict_id: 0,
dict_is_ordered: false,
metadata: {},
},
},
```
The two `t2` fields have incorrect nullability flag inferred. Unless I am
missing something, the `plan_selection` method does not need to scan the data
to infer the correct nullability flags. All it needs is the understanding of
which join it is processing and which side of that join the columns are coming
from.
Does it make sense?
--
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]
