implement lead and lag with 2nd and 3rd argument

[jimexist]

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
(This section helps Arrow developers understand the context and why for this feature, in addition to the what)

follow up with #553 , we can additionally support 2nd and 3rd argument

Describe the solution you'd like
A clear and concise description of what you want to happen.

Similar to postgresql function definitions

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[jgoday]

Hi @jimexist, Could I take a look at this ?

As I understand it:

• a BuiltInWindowFunctionExpr and a PartitionEvaluator has to be implemented under physical_plan/expressions, lag and lead functions should be created with a name, an expression, and the offset/default_value optional arguments.

• return_type_for_built_in and signature_for_built_in should be changed for Lag/Lead (physical_plan/window_functions)

• signature has to be a Signature::OneOf( (expr -> result), (expr, offset) -> result, (expr, offset, default_value) -> result )

I'm probably missing some details, but would this approach be valid ?

[jimexist]

Hi @jimexist, Could I take a look at this ?

As I understand it:

• a BuiltInWindowFunctionExpr and a PartitionEvaluator has to be implemented under physical_plan/expressions, lag and lead functions should be created with a name, an expression, and the offset/default_value optional arguments.

• return_type_for_built_in and signature_for_built_in should be changed for Lag/Lead (physical_plan/window_functions)

• signature has to be a Signature::OneOf( (expr -> result), (expr, offset) -> result, (expr, offset, default_value) -> result )

I'm probably missing some details, but would this approach be valid ?

Go ahead and thanks!

the way is see it currently there is no easy way to express heterogeneity in arg types so i would stick with any and check inside the actual execution phase.

[jimexist]

Hi @jimexist, Could I take a look at this ?

As I understand it:

• a BuiltInWindowFunctionExpr and a PartitionEvaluator has to be implemented under physical_plan/expressions, lag and lead functions should be created with a name, an expression, and the offset/default_value optional arguments.

• return_type_for_built_in and signature_for_built_in should be changed for Lag/Lead (physical_plan/window_functions)

• signature has to be a Signature::OneOf( (expr -> result), (expr, offset) -> result, (expr, offset, default_value) -> result )

I'm probably missing some details, but would this approach be valid ?

And you don't need to creat a different expr or physical expr you can just modify the current one to take additional arguments

[jgoday]

Oh, sorry, I was looking to an old fork, I didn't realize that lag and lead were already implemented in the main branch :)
All clear then, I will try to implement the offset and default_value arguments only

[jgoday]

I have created a PR (#687) and commented some doubts about the implementation in it.