gruuya commented on issue #8008:
URL:
https://github.com/apache/arrow-datafusion/issues/8008#issuecomment-1794563532
> I think one reason causing this issue is that the qualifier is sometimes
present in the expr name (or column name), and sometimes is not:
Actually the qualifier is never inferred from an expression name, as
demonstrated in `ExprSchemable::to_fields`, it is left blank in all cases
except `Expr::Column` in which case it gets passed on to the schema/field.
> The first column's name is a, but this doesn't mean it doesn't have a
qualifier, and the qualifier won't appear. The qualifier is always a pain point
when aliasing the new expr. We have to choose whether or not to include the
qualifier in the alias string.
In case of projecting `col("a")` above the reason that column does have a
qualifier is that `LogicalPlanBuilder::project` first calls `normalize_col`
against the original schema, which populates the qualifier into the
`Expr::Column` expression. Only then does it call `Projection::try_new` with
the normalized expressions, which in turn invokes `ExprSchemable::to_fields` to
get the final schema. Note that this can't work for renamed columns since
they're not present in the input schema. Again, including the qualifier in the
alias name itself will only result in the qualifier becoming a part of the
`DFiield::name`, but will leave the actual `DFiield::qualifier` empty.
> From this point, maybe Alias should contain a qualifier or relation like
Column? But I am concerned that having both Alias and AliasQualified at the
same time would be confusing.
Yeah, having both might be confusing (was inspired by
`Expr::QualifiedWildcard` and `Expr::Wildcard`), though extending the existing
enum could also be more work.
--
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]
