alamb commented on code in PR #13664:
URL: https://github.com/apache/datafusion/pull/13664#discussion_r1882461644
##########
datafusion/common/src/column.rs:
##########
@@ -254,6 +305,23 @@ impl Column {
.collect(),
})
}
+
+ /// Attaches a [`Span`] to the [`Column`], i.e. its location in the source
+ /// SQL query.
+ pub fn with_span(mut self, span: Span) -> Self {
+ self.spans = vec![span];
Review Comment:
should this perhaps append a span to the Column rather than overwrite it?
##########
datafusion/common/src/dfschema/mod.rs:
##########
@@ -113,6 +117,10 @@ pub struct DFSchema {
field_qualifiers: Vec<Option<TableReference>>,
/// Stores functional dependencies in the schema.
functional_dependencies: FunctionalDependencies,
+ /// The location in the source code where the fields are defined (e.g. in
Review Comment:
This seems somewhat strange to me as the schema may not be defined in the
query
Maybe we can avoid adding this as part of V1
##########
datafusion/common/src/column.rs:
##########
@@ -18,22 +18,35 @@
//! Column
use arrow_schema::{Field, FieldRef};
+use sqlparser::tokenizer::Span;
use crate::error::_schema_err;
use crate::utils::{parse_identifiers_normalized, quote_identifier};
use crate::{DFSchema, Result, SchemaError, TableReference};
+use derivative::Derivative;
use std::collections::HashSet;
use std::convert::Infallible;
use std::fmt;
use std::str::FromStr;
/// A named reference to a qualified field in a schema.
-#[derive(Debug, Clone, PartialEq, Eq, Hash, PartialOrd, Ord)]
+#[derive(Debug, Clone, Derivative)]
+#[derivative(PartialEq, Eq, Hash, PartialOrd, Ord)]
pub struct Column {
/// relation/table reference.
pub relation: Option<TableReference>,
/// field/column name.
pub name: String,
+ #[derivative(
Review Comment:
From my perspective some design goals should be:
1. Make it easy for someone reading the DataFusion source code to understand
what is going on
2. If people are not interested in the span / diagnostic information they
can ignore it
From my perspective, using new crates does reduce the amount of code in the
DataFusion crate, but can often increase cognitive load (as now to understand
the DataFusion code you need to understand the crates)
> I think the AttachedToken approach that we took in sqlparser could be a
functionally equivalent alternative. And I understand that not everybody might
be familiar with derivative.
Yeah, that is why I think AttachedToken might be better in this case
--
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: github-unsubscr...@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org
For additional commands, e-mail: github-h...@datafusion.apache.org
