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

[github-actions]

Thank you for your contribution. Unfortunately, this pull request is stale because it has been open 60 days with no activity. Please remove the stale label or comment or this will be closed in 7 days.