I think this would be useful. A builder will allow us to extend the operand model, and evolution will not tend to break existing code.
If someone takes this one, I’d like to see some mock-ups: one or two existing rules rewritten to use the proposed new API. Let's iterate on that, and agree an API we like, before changing all of the existing rules. > On Feb 6, 2019, at 3:46 AM, Vladimir Sitnikov <[email protected]> > wrote: > > Hi, > > You might have seen Calcite's way to declare RelOptRule operands: > operand(Filter.class, ..., operand(Project.class, ...)) > It is somewhat clean and understandable, however it is hard to scale in > terms of adding features to the operands. > > It looks like builders would help there. > I've logged https://issues.apache.org/jira/browse/CALCITE-2832 for that. > > Even though I would love to implement that, I find I haven't much time for > that at the moment (e.g. I haven't time to review my own PRs > <https://github.com/apache/calcite/pulls/vlsi> :) ) > On the other hand I think CALCITE-2832 might be a good start for someone > interested in how rules are used and how they work, so please feel free to > pick that up, especially if you are looking for something "simple" to get > accustomed with planner rules. > > Vladimir
