andygrove commented on a change in pull request #55:
URL: https://github.com/apache/arrow-datafusion/pull/55#discussion_r619815966
##########
File path: datafusion/src/logical_plan/expr.rs
##########
@@ -27,14 +27,89 @@ use aggregates::{AccumulatorFunctionImplementation,
StateTypeFunction};
use arrow::{compute::can_cast_types, datatypes::DataType};
use crate::error::{DataFusionError, Result};
-use crate::logical_plan::{DFField, DFSchema};
+use crate::logical_plan::{DFField, DFSchema, DFSchemaRef};
use crate::physical_plan::{
aggregates, expressions::binary_operator_data_type, functions,
udf::ScalarUDF,
};
use crate::{physical_plan::udaf::AggregateUDF, scalar::ScalarValue};
use functions::{ReturnTypeFunction, ScalarFunctionImplementation, Signature};
use std::collections::HashSet;
+/// A named reference to a qualified filed in a schema.
+#[derive(Debug, Clone, PartialEq, Eq, Hash)]
+pub struct Column {
+ /// relation/table name.
+ pub relation: Option<String>,
+ /// field/column name.
+ pub name: String,
Review comment:
Should we consider supporting compound names here so that we can
eventually support reference nested types?
Perhaps Column could be an enum?
```rust
enum Column {
Simple(Option<String>, String),
Compound(Option<String>, Vec<String>)
}
```
##########
File path: datafusion/src/logical_plan/expr.rs
##########
@@ -27,14 +27,89 @@ use aggregates::{AccumulatorFunctionImplementation,
StateTypeFunction};
use arrow::{compute::can_cast_types, datatypes::DataType};
use crate::error::{DataFusionError, Result};
-use crate::logical_plan::{DFField, DFSchema};
+use crate::logical_plan::{DFField, DFSchema, DFSchemaRef};
use crate::physical_plan::{
aggregates, expressions::binary_operator_data_type, functions,
udf::ScalarUDF,
};
use crate::{physical_plan::udaf::AggregateUDF, scalar::ScalarValue};
use functions::{ReturnTypeFunction, ScalarFunctionImplementation, Signature};
use std::collections::HashSet;
+/// A named reference to a qualified filed in a schema.
+#[derive(Debug, Clone, PartialEq, Eq, Hash)]
+pub struct Column {
+ /// relation/table name.
+ pub relation: Option<String>,
+ /// field/column name.
+ pub name: String,
Review comment:
Should we consider supporting compound names here so that we can
eventually support nested types? For example `SELECT t1.customer.address.zip,
...`
Perhaps Column could be an enum?
```rust
enum Column {
Simple(Option<String>, String),
Compound(Option<String>, Vec<String>)
}
```
--
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
