Another quick thought as far as it concerns the IN operator would be to use RexCall as it is right now where the first operand in the list is a RexInputRef for instance and the rest are the literals. I assume that taking this direction would need to change a bit the respective SqlOperator.
I haven't thought of this thoroughly so maybe there are important things that I am missing. Best, Stamatis On Tue, Jul 21, 2020 at 12:41 AM Julian Hyde <[email protected]> wrote: > The name isn't very intuitive. > > The concept of a list and a comparison operator seems OK. As Vladimir > points out, it is somewhat similar to RexSubQuery, so maybe this could > be a sub-class (but organizing the data a bit more efficiently). > > I would be very wary of null semantics. RexNode scalar operators are > forced to do 3-valued logic, but this is almost a relational operator > and it would be better without that burden. > > Julian > > > > On Mon, Jul 20, 2020 at 3:45 AM Vladimir Sitnikov > <[email protected]> wrote: > > > > >Do you know what is the impact on Enumerable implementation? > > > > I guess there are plenty of options there. > > > > The key question regarding RexListCmp is as we introduce a new Rex node, > > all the planning rules and all engines > > must support it somehow. > > > > Technically speaking, we have RexSubQuery. > > Haisheng, have you considered an option to stick with RexSubQuery to > avoid > > having two more-or-less the same rex classes? > > > > Vladimir >
