[
https://issues.apache.org/jira/browse/CALCITE-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18142932#comment-18142932
]
Stamatis Zampetakis commented on CALCITE-7925:
----------------------------------------------
I am not against the idea of subclassing and obviously this is much more
powerful than what I proposed in CALCITE-7789. If this ticket is implemented
CALCITE-7789 is clearly redundant.
The obvious downside is that the more freedom you give to extensions the more
difficult is to keep things stable and working and more difficult is for the
base class to evolve.
Before we decide to make every simplify method public/protected (which in terms
of code its very easy to do) is there a more focused change/interface that
could solve the problem encountered here without necessitating inheritance and
subclassing? Concretely for the LIKE usecase how did you solve the problem?
What would you like the simplifier to do in this case for your database?
Since the discussion has started I think its a bit premature to close and
abandon the Jira directly. Even if we don't go all the way to the
implementation of the change if we reach consensus about a satisfactory
solution it could be taken up by someone else.
> 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)
