In some circumstances cast expression is not working

[mpurins-coralogix]

Describe the bug
When executing following query field in results has integer datatype instead of string.
SELECT cast(c as varchar) FROM (SELECT 1 as c)

To Reproduce
Pickup this commit -- coralogix@f5c0fc0
Run cast_failure test.

Expected behavior
I would expect that such test is passing, but currently it fails with following error

thread 'sql::cast::cast_failure' panicked at 'assertion failed: `(left == right)`
  left: `Utf8`,
 right: `Int64`', datafusion/core/tests/sql/cast.rs:32:5

Additional context
I think this is happening because cast expression is replaced with column expression in columnize_expr (https://github.com/apache/arrow-datafusion/blob/5621e3bbd050eeb79646240ec0a09426badfa162/datafusion/expr/src/utils.rs#L638) and I suspect that it started happening for such queries after following change -- https://github.com/apache/arrow-datafusion/pull/3222/files#diff-204cfc4f999c3d12dc065f323cb952fb0ecb33c5570eed8dc1fb52b806e87004L926

[HaoYang670]

Thanks a lot for your reporting @mpurins-coralogix !! I will fix this.

I think this is happening because cast expression is replaced with column expression in columnize_expr

Yes, you are definitely right. The Expr::Cast is ignored because e.display_name drops the cast expression. We should add another matching arm here for the Cast expression.

[HaoYang670]

By the way, there is no bug when you select from a view. For example:

❯ create view v as select 1 as a;
0 rows in set. Query took 0.003 seconds.
❯ explain select cast (a as float) from v;
+---------------+----------------------------------------------------+
| plan_type     | plan                                               |
+---------------+----------------------------------------------------+
| logical_plan  | Projection: CAST(v.a AS Float32)                   |
|               |   Projection: a, alias=v                           |
|               |     Projection: Int64(1) AS a                      |
|               |       EmptyRelation                                |
| physical_plan | ProjectionExec: expr=[CAST(a@0 AS Float32) as v.a] |
|               |   ProjectionExec: expr=[a@0 as a]                  |
|               |     ProjectionExec: expr=[1 as a]                  |
|               |       EmptyExec: produce_one_row=true              |
|               |                                                    |
+---------------+----------------------------------------------------+
2 rows in set. Query took 0.007 seconds.
❯ explain select cast (a as float) from (select 1 as a);
+---------------+-------------------------------------+
| plan_type     | plan                                |
+---------------+-------------------------------------+
| logical_plan  | Projection: a                       |
|               |   Projection: Int64(1) AS a         |
|               |     EmptyRelation                   |
| physical_plan | ProjectionExec: expr=[a@0 as a]     |
|               |   ProjectionExec: expr=[1 as a]     |
|               |     EmptyExec: produce_one_row=true |
|               |                                     |
+---------------+-------------------------------------+
2 rows in set. Query took 0.003 seconds.

This is because that we ignore the qualifier when finding the field,

match e.display_name() {
            Ok(name) => match input_schema.field_with_unqualified_name(&name) {
                Ok(field) => Expr::Column(field.qualified_column()),
                // expression not provided as input, do not convert to a column reference
                Err(_) => e,
            },
            Err(_) => e,

As a result, the field e cannot be found and we have to go to the Err(_) arm.
I am not sure why we use field_with_unqualified_name here. Any context here, cc @andygrove ?