Reuse alias if possible

[blaginin]

Which issue does this PR close?

• Follow up on Reuse last projection layer when renaming columns #14684 (comment)
• close Remove duplicated alias in Sort #14895

Rationale for this change

Currently, alias over alias creates an extra expression layer, which gets merged in optimize_projections through an expensive recursive function

What changes are included in this PR?

A small change to reuse an existing alias when possible. This affects two cases:

• Removes unnecessary info when displaying logical plans
• Simplifies expressions when optimize_projections isn't called (e.g., when there's only one projection and merge_consecutive_projections isn't run)

Are these changes tested?

Extended doctest

Are there any user-facing changes?

No.

[alamb]

Interestingly, I was working on a very similar PR last night:

• Do not double alias Exprs #15008

[blaginin]

yes, @alamb, I think we got on the same issue with unnest 😀 - I'm happy to keep working on mine unless you want to take over?

[alamb]

yes, @alamb, I think we got on the same issue with unnest 😀 - I'm happy to keep working on mine unless you want to take over?

Yes, indeed -- something is going on with unnest.

It would be great if you wanted to take over

Feel free to pull over the test case from https://github.com/apache/datafusion/pull/15008/files as well

[blaginin]

@goldmedal FYI, this is another change to unnest - I want to always do alias to make behaviour more consistent

[goldmedal]

I don't get why this way can make behavior more consistent 🤔. Could you explain more?

[goldmedal]

BTW, I'm considering how to fix the issue mentioned in (#15090 (comment)). I think add an alias for the unnest may be a good idea.

I think it should like

Suggested change

	unnest_relation.alias(Some(self.new_table_alias(alias.to_string(), vec![])));
	unnest_relation.alias(Some(self.new_table_alias("unnset_table_1", vec![alias.to_string()])));

Then, we can get the result like

SELECT "UNNEST(make_array(Int64(1),Int64(2),Int64(3)))" FROM UNNEST([1, 2, 3]) AS unnest_table ("UNNEST(make_array(Int64(1),Int64(2),Int64(3)))")

It can not only fit what you want to do but generate a valid SQL. WDYT?

[goldmedal]

#15233
I created an issue to explain more.

[blaginin]

I think this is an edge case example

SELECT * from UNNEST([1,2,3]), UNNEST([1,2,3,4])

is transformed into

SELECT UNNEST(make_array(Int64(1),Int64(2),Int64(3))), UNNEST(make_array(Int64(1),Int64(2),Int64(3),Int64(4))) FROM UNNEST([1, 2, 3]) AS unnset_table_1 (UNNEST(make_array(Int64(1),Int64(2),Int64(3)))) CROSS JOIN UNNEST([1, 2, 3, 4]) AS unnset_table_1 (UNNEST(make_array(Int64(1),Int64(2),Int64(3),Int64(4))))