feat: Support ANY/ALL operators

[ovr]

Hello!

Ref issue: #476

I want to support a = ANY(expr) in DF, but after reviewing I come to decision that it requires changes in sql-parser to simplify code (because hacking when the right side is a function is a super tricky)

Thanks

[ovr]

@alamb WDYT? Should I create a separate issue for supporting AllOperatorSubquery & AnyOperatorSubQuery?

[coveralls]

Pull Request Test Coverage Report for Build 2277494621

• 31 of 33 (93.94%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.02%) to 90.444%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/parser.rs	15	17	88.24%

Totals
Change from base Build 2273021751:	0.02%
Covered Lines:	8177
Relevant Lines:	9041

---

💛 - Coveralls

[alamb]

Ho @ovr --- sounds like an exiting feature!

Looking at the postgres documentation, https://www.postgresql.org/docs/current/functions-subquery.html it seems to me like ANY / ALL can be combined with any operator that results in a boolean, not just <, <=, =, !=, >=, >

For example, with ~:

alamb=# select x from test where x ~ ANY (select x from test);
  x  
-----
 foo
(1 row)

What would you think about adding something like

 /// `ANY()`
    Any(Box<Expr>),

This might be more in keeping with the spirit of sql-parser-rs to parse the query faithfully without applying any implicit semantics to it.

@alamb WDYT? Should I create a separate issue for supporting AllOperatorSubquery & AnyOperatorSubQuery?

I don't think separate issues are necessary

[ovr]

@alamb Oh, I see, but anyway what about LIKE/AND/OR operators which are supported in Binary expression but is not supported for ANY & ALL operators? Another question is, whether it will lead to a nonimplicit pattern machine on the DF side?

If it's okey, I will update a PR to reflect your idea. Big thanks to you!

[alamb]

@alamb Oh, I see, but anyway what about LIKE/AND/OR operators which are supported in Binary expression but is not supported for ANY & ALL operators? Another question is, whether it will lead to a nonimplicit pattern machine on the DF side?

I am not quite sure what you mean about "nonimplicit pattern match on the DF side"

Maybe you could do something like the following with a match guard (totally untested):

sqlparser::Expr::BinaryExpr {
  left, 
  op
  right
} if is_any_expr(&right) => {...}
  }
...

and

/// returns true of `expr` represents an `Any` clause
fn is_any_expr(expr: sqlparser::Expr) ->bool)  {
...
}

I found this style worked pretty well in simplify_expressions:

https://github.com/apache/arrow-datafusion/blob/master/datafusion/core/src/optimizer/simplify_expressions.rs#L498-L508

[ovr]

@alamb Oh, I see your idea about simplifying it and wrapping it on the right side of the BinaryExpression expression. I've updated the PR as you suggested. Thanks

[alamb]

Looks great to me @ovr 👍

[alamb]

👍

[alamb]

👍 looks good to me