andre-cc-natzka opened a new issue, #4681:
URL: https://github.com/apache/arrow-datafusion/issues/4681

   **Describe the bug**
   We ran into a problem when running queries that do not explicitly mention 
some dimension(s). We found out that, while handling these dimensions, an 
`Expr::Wildcard` is created. This in itself is not a problem, but may become 
one when the `type_coercion` and `unwrap_cast_in_comparison` optimization rules 
call the `display_name` method on this expression, which is not allowed because 
the `create_name` method called inside `display_name` does not support 
`Expr::Wildcard`.
   
   To go a bit more into detail, the `optimize_internal` methods from 
`type_coercion` and `unwrap_cast_in_comparison` call the 
`rewrite_preserving_name` function from `datafusion/optimizer/src/utils.rs`, 
which just rewrites an expression while keeping its name unchanged. It calls 
`name_for_alias`, which gets the name of an expression by calling 
`display_name`, which in turn gives rise to the warnings.
   
   This only prevents the `type_coercion` and `unwrap_cast_in_comparison` 
optimization rules from being applied to the schema dimensions we are not 
considering, so should not be a problem, but gives rise to some annoying 
warnings during query execution.
   
   **To Reproduce**
   This behavior can be recovered by running queries where one or several cube 
dimensions are not explicitly mentioned, giving rise to `Expr::Wildcard`s. When 
trying to apply the optimization rules `type_coercion` and 
`unwrap_cast_in_comparison` , the following output is obtained:
   ```
   WARN datafusion_optimizer::optimizer: Skipping optimizer rule 
'type_coercion' due to unexpected error: Internal error: Create name does not 
support wildcard.
   WARN datafusion_optimizer::optimizer: Skipping optimizer rule 
'unwrap_cast_in_comparison' due to unexpected error: Internal error: Create 
name does not support wildcard.
   ```
   
   **Expected behavior**
   We expect the query to run with no warnings at all, and let the optimization 
rules be applied to all the sub-plans (even if it is not required for query 
execution). To do that, we must find a way to allow to rewrite an expression of 
type `Expr::Wildcard` without calling `display_name()`, since this will give 
rise to the above mentioned error message originating from `create_name()`. A 
simple workaround could be, in the `name_for_alias` function, to consider 
separately the case in which the expression is of type `Expr::Wildcard`, and 
make sure it is given a reasonable name (e.g. "*") instead of calling 
`display_name()`. Another solution could be to introduce the change directly in 
`create_name()`, by modifying the action in case `Expr::Wildcard` is found.
   


-- 
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]

Reply via email to