Github user NickolayVasilishin commented on the issue: https://github.com/apache/flink/pull/2870 Also the last commit represents possible way of implementing subquery IN operator. On one hand, it's really simple implementation, all work delegates to already proprely working components, generated logical plan looks practically identical to one generated in similar SQL query. On the other hand, it maybe looks ugly, because it's placed in one of top layers of API. Also we can't use `validateInputs` method there because field on the right side isn't resolved yet. But I think, there are ways to validate inputs. I've tried to solve this problem in more convinient way. It looks like implementation of IN for literals, but I've faced problems: - generating `RexNode` for IN qubquery. I've tried to use all possible variants, but logical plan for subquery was incorrect (had duplicated IN expression, for example). It's solvable, but needs changes in `Calcite`, I think. - implementation of `SubQueryVisitor` and `RelShuttle`. I didn't find ways to reuse existing code in this case. Also there isn't any existing examples which I was able to use as template. - it's not clear for me, how to use results of subquery in the operator (especially relationship between generated code). - generated logical plan differs from one generated in SQL query. Also I thought about substitution of plan with inner join instead of plan with IN operator somewhere in code. I assumed that the same thing takes place in SQL API, but Calcite translates `IN` to `INNER JOIN` at the beginning. That's why I decided to implement subqueries this way.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---