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

Draft: Extend Expr::ScalarUDF to support Expr for ScalarUDF #8222

Closed
wants to merge 1 commit into from

Conversation

2010YOUY01
Copy link
Contributor

Which issue does this PR close?

POC for #8157

Rationale for this change

The rationale is described in #8180
This PR is just used to demonstrate approach 1 in #8180

What changes are included in this PR?

  1. When Expr for functions is created using call_fn(), it first stores a ScalarUDF with only name and stub implementation inside
  2. During 1st analyzing rule, resolve name-only UDF into the implementation from the function registry

This approach requires less change to existing code.
(I'm wondering do you have any thoughts on this one? @alamb )

Are these changes tested?

Are there any user-facing changes?

@github-actions github-actions bot added the logical-expr Logical plan and expressions label Nov 15, 2023
Err(e) => Err(e),
Err(_) => {
// Constructing a `ScalarUDF` with only name and stub impl/return_type...
// This unresolved UDF will be resolved during analyzing using registered functions
Copy link
Contributor

Choose a reason for hiding this comment

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

If you can make this work, it seems like a good idea to me.

However, it is not clear to me how the subsequent passes will know they have to resolve this particular scalar UDF though 🤔 so I am not sure this approach is viable

Specifically, how would the code look that the analysis pass used to test if a ScalarUDF was unresolved or not?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a great point, without enum the implementation seems a bit vulnerable to bugs
I think we can either make Expr::ScalarFunction or Expr::ScalarUDF a enum, since the long-term goal is to remove BuiltinScalarFunction they should be same.
I'll check which way can make future migration easier

pub enum ScalarFunctionDefinition {
  /// Resolved to a user defined function
  UDF(ScalarUDF),
  /// A scalar function that will be called by name
  Name(Arc<str>),
}

#[derive(Clone, PartialEq, Eq, Hash, Debug)]
pub struct ScalarUDF {
    /// The function
    pub fun: ScalarFunctionDefinition,
    /// List of expressions to feed to the functions as arguments
    pub args: Vec<Expr>,
}
pub enum ScalarFunctionDefinition {
  /// Resolved to a built in scalar function
  /// (will be removed long term)
  BuiltIn(built_in_function::BuiltinScalarFunction),
  /// Resolved to a user defined function
  UDF(ScalarUDF),
  /// A scalar function that will be called by name
  Name(Arc<str>),
}

#[derive(Clone, PartialEq, Eq, Hash, Debug)]
pub struct ScalarFunction {
    /// The function
    pub fun: ScalarFunctionDefinition,
    /// List of expressions to feed to the functions as arguments
    pub args: Vec<Expr>,
}

@2010YOUY01 2010YOUY01 closed this Nov 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
logical-expr Logical plan and expressions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants