Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SPARK-51310][SQL] Resolve the type of default string producing expressions #50053

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

stefankandic
Copy link
Contributor

@stefankandic stefankandic commented Feb 23, 2025

What changes were proposed in this pull request?

Add casts to DefaultStringProducingExpression to have the correct type based on the default string type.

Currently, we can only test this on views, until we implement schema level collations when we will be able to test the behavior on newly created tables as well.

Why are the changes needed?

These expressions should return the default string type, which could be different in some DDL commands.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

Added unit tests for view creation.

Was this patch authored or co-authored using generative AI tooling?

No.

@github-actions github-actions bot added the SQL label Feb 23, 2025
@stefankandic stefankandic changed the title [DRAFT] Resolve default string exprs [DRAFT] Resolve default string producing expressions Feb 24, 2025
@stefankandic stefankandic changed the title [DRAFT] Resolve default string producing expressions [SPARK-51310][SQL] Resolve the type of default string producing expressions Feb 25, 2025
@stefankandic stefankandic marked this pull request as ready for review February 25, 2025 11:26
@stefankandic
Copy link
Contributor Author

@cloud-fan @dejankrak-db please take a look, thanks!

@@ -28,6 +28,7 @@ import org.apache.spark.sql.types.{DataType, StringType}
* collation from the corresponding object (table/view -> schema -> catalog).
*/
object ResolveDDLCommandStringTypes extends Rule[LogicalPlan] {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: you can remove this extra line now


plan.mapChildren { operator =>
operator.mapExpressions { expression =>
expression.mapChildren {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does .mapChildren transform the whole expression tree?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

def mapChildren(f: BaseType => BaseType): BaseType = {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

    if (containsChild.nonEmpty) {
      withNewChildren(children.map(f))
    } else {
      this
    }

There is no recursion, how does it transform the full tree?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you are right, sorry I missed this. Changed the behavior to visit recursively and added new test to verify this behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants