Move logical expression type-coercion code from physical-expr crate to expr crate

[andygrove]

Which issue does this PR close?

Closes #2251.

Rationale for this change

We have logic to determine the return type of various logical expressions and this logic is called from expr_schema.rs in the logical_plan module, but the code is located in the physical-expr crate and it does not need to be there.

We could move this logic into the datafusion-expr crate instead and remove many logical plan dependencies on the datafusion-physical-expr crate, as a step towards to moving the logical plan itself to datafusion-expr, which would allow us to have logical expressions that reference logical plans (needed for subquery support).

What changes are included in this PR?

This PR moves logical type coercion code from datafusion-physical-expr to datafusion-expr. There are no functional changes.

Note that physical type coercion logic remains in the physical-expr crate.

• Move aggregate type code (0b7327d)
• Move window function type code (7bc25ae)
• Move scalar function type code (6f1eadb)

Are there any user-facing changes?

Yes - code is moved between crates, so users will need to update their imports.

[andygrove]

@alamb @jimexist Apologies for the monster PR. I am happy to try and break this down into smaller changes if that will help with reviews. There are no functional changes, just moving code around to fix one of the dependency issues that is blocking me from making progress with subquery support.

I'm not sure who else I should be @ mentioning here so feel free to tag others that you think should review this.

[yjshen]

I've thought of a trait with supported_arg_type and return_type methods before but seems not much difference.

[alamb]

I think moving more coercion / expr logic into datafusion-expr makes sense -- thank you @andygrove

FWIW I think there was some discussion of keeping the Expr -> PhysicalExpr mapping isolated (including the type coercion) to allow different implementations of PhysicalExprs for each Expr (I think @jorgecarleitao discussed this 1+ year ago).

I haven't heard this idea mentioned for a while and I think it would be quite challenging to implement given the current DataFusion codebase, and I think coercion logic close to the exprs is 👍

cc @liukun4515 who I think has also had some thoughts in this area

[jorgecarleitao]

The background of my thoughts back then was: there are two types of "coercion rules":

• coercion rules that exist as a consequence of the supported ops from the physical engine (e.g. i32 + i64 -> cast(i32 AS i64) + i64 when the engine does not support i32 + i64).

• coercion rules related to the semantic meaning of what the user wants. For example, a user usually wants sum(Vec<u8>) to be u64, not u8, to avoid numeric overflows.

imo the former is part of the step logical -> physical, the latter is part of the (run-time) type checking done when performing logical planning for schema resolution (i.e. what schema will the logical plan have)