Rename Expr::display_name to Expr::schema_name, make UNNEST naming conform to convention

[jayzhan211]

Which issue does this PR close?

Part of #11782
Closes #.

Rationale for this change

display_name is used widely but it is actually the different things from Display trait. After taking a look, I think schema_name is a less confusing term, since we usually build the name with display_name for schema / field.

What changes are included in this PR?

schema_name is introduced and we should continue to use the schema_name for schema/field later on.
display_name is removed and we should use Display trait instead

Are these changes tested?

Are there any user-facing changes?

[alamb]

Thanks @jayzhan211 -- this looks like an improvement to me 🙏

I think making a deprecated function would be really nice to help people upgrade

I also think if we are going to be messing around with the API we should consider updating the API to avoid allocations when possible

[alamb]

the old error message was nicer -- maybe we can update the code that generates this message to be nicer too 🤔

[alamb]

If we are going to introduce a new API anyways, what do you think about making an API that doesn't require allocating a new string and making it infallable. Something like

Suggested change

	pubfn schema_name(&self) -> Result<String>{
	pubfn schema_name<'a>(&'aself) -> implDisplay + 'a{

We could probably then implement a new type thing and mostly use the same code:

// new type wrapperstructSchemaDisplay<'a>(&'aExpr);impl<'a>DisplayforSchemaDisplay<'a>{fn fmt(&self,f:&mutFormatter<'_>) -> fmt::Result{matchself{// The same as DisplayExpr::Column(_)
| Expr::Literal(_)
| Expr::ScalarVariable(..)
| Expr::Sort(_)
| Expr::OuterReferenceColumn(..)
| Expr::Placeholder(_)
| Expr::Wildcard{ .. } => write!(f,"{self}")?,
...}}returnSchemaDisplay(self)

The benefit of doing this would be anywhere it needed to get formatted would not require a copy

println!("This would not allocated a String: {}", expr.schema_name());

// get schema name as a string:let schema_name = expr.schema_name().to_string();

[jayzhan211]

This looks cool!

[alamb]

Here is a suggesiton for how to improve this documentation:

Suggested change

	/// Returns the name for schema / field that is different from Display
	/// Most of the expressions are the same as Display
	/// Those are the main difference
	/// 1. Alias, where excludes expression
	/// 2. Cast / TryCast, where takes expression only
	/// The name of the column (field) that this `Expr` will produce.
	///
	/// For example, for a projection (e.g. `SELECT <expr>`) the resulting arrow
	/// [`Schema`] will have a field with this name.
	///
	/// Note that the resulting string is subtlety different than the `Display`
	/// representation for certain `Expr`. Some differences:
	///
	/// 1. [`Expr::Alias`], which shows only the alias itself
	/// 2. [`Expr::Cast`] / [`Expr::TryCast`], which only displays the expression
	///
	/// # Example
	/// ```
	/// # use datafusion_expr::{col, lit};
	/// let expr = col("foo").eq(lit(42));
	/// assert_eq!("foo = Int32(42)", expr.schema_name().unwrap());
	///
	/// let expr = col("foo").alias("bar").eq(lit(11));
	/// assert_eq!("bar = Int32(11)", expr.schema_name().unwrap());
	/// ```
	///
	/// [`Schema`]: arrow::datatypes::Schema

[alamb]

I think it makes sense as long as the cast is still in plans (which it is)

[alamb]

Suggested change

	/// Returns the user-defined schema name of the UDF given the arguments
	/// Returns the name of the column this expression would create
	///
	/// See [`Expr::schema_name`] for details

Maybe it is also worth doing the impl Display thing here too which would allow avoiding these string allocations

[jayzhan211]

It seems I need another SchemaFunctionDisplay for replacing String with impl Display in UDFImpl. I would like to hold on to the change for function

[alamb]

makes sense -- I don't think there is any reason that this impl Display thing has to be done -- I was thinking it might be worth exploring if we were already changing the code anyways

[alamb]

LGTM -- thanks @jayzhan211

[alamb]

shall we file a ticket to track this (maybe others would be interested in helping)

[jayzhan211]

Sure

[jayzhan211]

I notice that #11198 is filed already.

[jayzhan211]

Thanks @alamb