[
https://issues.apache.org/jira/browse/CALCITE-4183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183597#comment-17183597
]
Julian Hyde commented on CALCITE-4183:
--------------------------------------
I am concerned that if we add the {{withOperandFor(Class filterClass, Class
setOpClass)}} method, someone will want to add a predicate to the filter - e.g.
only allow filters whose condition does not contain the LIKE function - and
will think they need to create a {{withOperandFor(Class filterClass, Predicate
filterPredicate, Class setOpClass)}} method, when actually they can achieve
anything they want by calling the {{withOperandSupplier}} method.
> FilterSetOpTransposeRule constructor should allow for user defined Filter and
> SetOp classes
> -------------------------------------------------------------------------------------------
>
> Key: CALCITE-4183
> URL: https://issues.apache.org/jira/browse/CALCITE-4183
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.24.0
> Reporter: Sean Broeder
> Priority: Major
> Labels: pull-request-available
> Original Estimate: 168h
> Time Spent: 20m
> Remaining Estimate: 167h 50m
>
> The current FilterSetOpTransposeRule constructor simply takes a
> RelBuilderFactory. Adding an additional constructor would allow more
> flexibility for user specific Filter and SetOp classes and follows behavior
> already allowed for several other rules.
> For example:
> /**
> * Creates a FilterSetOpTransposeRule that uses a generic
> * {@link Filter} and {@link SetOp}
> * @param filterClass filter class
> * @param setOpClass setOp class
> * @param relBuilderFactory builder factory for relational expressions
> */
> public FilterSetOpTransposeRule(Class<? extends Filter> filterClass,
> Class<? extends SetOp> setOpClass,
> RelBuilderFactory relBuilderFactory) {
> super(
> operand(filterClass,
> operand(setOpClass, any())),
> relBuilderFactory, null);
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
