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

feat: issue #8969 adding position function #8988

Merged
merged 2 commits into from
Feb 2, 2024
Merged

Conversation

Lordworms
Copy link
Contributor

Which issue does this PR close?

#8969

Closes #.

Rationale for this change

What changes are included in this PR?

adding a new function position(str in fullstr)

Are these changes tested?

yes, but not fully tested

Are there any user-facing changes?

@github-actions github-actions bot added sql SQL Planner logical-expr Logical plan and expressions physical-expr Physical Expressions sqllogictest SQL Logic Tests (.slt) labels Jan 24, 2024
@Lordworms Lordworms force-pushed the issue_8969 branch 5 times, most recently from e63a87d to 2ef9087 Compare January 25, 2024 17:53
Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

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

Thank you @Lordworms -- this is looking good and close. I wonder if we need a whole new function

@@ -570,6 +570,48 @@ pub fn uuid(args: &[ColumnarValue]) -> Result<ColumnarValue> {
let array = GenericStringArray::<i32>::from_iter_values(values);
Ok(ColumnarValue::Array(Arc::new(array)))
}
/// position function, similar logic as instr
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there any difference to instr? If not maybe we can reuse the instr function (see my comment below)

@@ -514,7 +514,9 @@ impl<'a, S: ContextProvider> SqlToRel<'a, S> {
SQLExpr::Struct { values, fields } => {
self.parse_struct(values, fields, schema, planner_context)
}

SQLExpr::Position { expr, r#in } => {
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

schema: &DFSchema,
planner_context: &mut PlannerContext,
) -> Result<Expr> {
let fun = BuiltinScalarFunction::Position;
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder would it be possible here to reuse the existing BuiltinScalarFunction::Instr rather than creating a new function for position?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think there is no difference between the two functions, but I just browsed the previous implementation, each scalarbilutin function would have a corresponding implementation in string_expression, I don't know whether it is good to maintain the consistency or not. I can definitely reuse instr though.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should reuse Instr unless there is a compelling reason to have a new function

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, I will fix it soon

Copy link
Contributor

Choose a reason for hiding this comment

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

THank you 🙏

Copy link
Contributor

Choose a reason for hiding this comment

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

I think if we changed this code to use BuiltinScalarFunction::Instr we could remove BuiltinScalarFunction::Position entirely which would make this PR much simpler and address @Weijun-H and my concerns about duplication

What do you think @Lordworms

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, I would do this right now, sorry I have been working on another issue

Copy link
Contributor

Choose a reason for hiding this comment

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

YES, I would do this right now, sorry I have been working on another issue

No rush -- sorry I want to make it clear there is no pressure here. I just wanted to make sure your PR wasn't waiting on feedback (as I get anxious when there are so many PRs waiting on review)

Thank you for all your help

@Lordworms Lordworms force-pushed the issue_8969 branch 2 times, most recently from 911c4be to 48244df Compare January 25, 2024 20:26
datafusion/expr/src/built_in_function.rs Outdated Show resolved Hide resolved
datafusion/physical-expr/src/functions.rs Outdated Show resolved Hide resolved
Copy link
Member

@Weijun-H Weijun-H left a comment

Choose a reason for hiding this comment

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

Thanks @Lordworms 👍 I think this pr is close.

@@ -1498,6 +1505,7 @@ impl BuiltinScalarFunction {
BuiltinScalarFunction::Reverse => &["reverse"],
BuiltinScalarFunction::Right => &["right"],
BuiltinScalarFunction::Rpad => &["rpad"],
BuiltinScalarFunction::Position => &["position"],
Copy link
Member

Choose a reason for hiding this comment

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

To reduce duplication, please add position as an alias in the Instr field.

@alamb
Copy link
Contributor

alamb commented Jan 31, 2024

I think this PR is just waiting on implementing @Weijun-H 's suggestion to use a alias rather than a new function #8988 (comment)

Marking as a draft to signal it isn't waiting on feedback. Please mark as ready for review when it is ready for another look

@alamb alamb marked this pull request as draft January 31, 2024 21:03
@Lordworms Lordworms marked this pull request as ready for review January 31, 2024 21:06
@@ -1487,7 +1487,7 @@ impl BuiltinScalarFunction {
BuiltinScalarFunction::Chr => &["chr"],
BuiltinScalarFunction::EndsWith => &["ends_with"],
BuiltinScalarFunction::InitCap => &["initcap"],
BuiltinScalarFunction::InStr => &["instr"],
BuiltinScalarFunction::InStr => &["instr", "position"],
Copy link
Member

Choose a reason for hiding this comment

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

👍

Copy link
Member

Choose a reason for hiding this comment

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

Is it necessary to create a new file for in test 🤔 ?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think it is necessary, but I also don't think it hurts either.

Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

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

Thank you @Lordworms and @Weijun-H

I agree with @Weijun-H that it might make sense to consolidate the test with the other string functions https://github.com/apache/arrow-datafusion/pull/8988/files#r1475910565, perhaps one of you could make a follow on PR to do so.

But thank you for sticking with this @Lordworms 🏆

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think it is necessary, but I also don't think it hurts either.

@alamb alamb merged commit 7641a32 into apache:main Feb 2, 2024
23 checks passed
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 sql SQL Planner sqllogictest SQL Logic Tests (.slt)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants