[ 
https://issues.apache.org/jira/browse/CALCITE-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18140846#comment-18140846
 ] 

Julian Hyde commented on CALCITE-7925:
--------------------------------------

You want Calcite to support subclassing as a means of extending/customizing 
{{{}RexSimplify{}}}. Clearly it is in your interests that we do this. But can 
you make the case that it is in the interest of Calcite's whole community, 
including its maintainers? Because if we allow subclassing, any change we make 
could potentially break your code, and that of anyone else who has subclassed 
{{{}RexSimplify{}}}. Code that we cannot even see. We will have to be a lot 
more cautious what changes we make going forward.

> Proposal: Change RexSimplify::simplify* methods to "protected"
> --------------------------------------------------------------
>
>                 Key: CALCITE-7925
>                 URL: https://issues.apache.org/jira/browse/CALCITE-7925
>             Project: Calcite
>          Issue Type: Improvement
>            Reporter: Steve Carlin
>            Priority: Major
>
> I had to create a custom RexSimplify to deal with some difference that my 
> database has with the way Calcite handles NULLs.
> This all works fine since I am able to inherit most of the behavior of 
> RexSimplify with very small custom changes.
> I just came across a problem though. At this point, I'm not sure if it is a 
> Calcite bug or if it's a behavior specific to my database.  I'll mention the 
> specifics at the end, but that's irrelevant to the purpose of this Jira. 
> Whether it's a bug or not, I think overrides on simplifications should be 
> allowed and the methods should be extensible/overrideable.
> I would like the ability to override specific implementation details on a 
> specific operator.  In my case, I'd like to override
> "simplifyLike(RexCall e, RexUnknownAs unknownAs)"
> But I cannot due this due to it being private.  Can we change this to be 
> "protected"?
> ---
> To be specific about the problem I'm hitting:
> In my LIKE clause, I have " s LIKE 'a\\%%' "   My database treats the first 
> four characters  as the string "a" plus an escaped percentage sign.  The 
> fifth "%" character is treated as a wildcard.
> The simplifyLike behavior reduces all multiple wildcards into a single 
> wildcard. So by "simplifying" the expression, I lose the wildcard character.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to