[
https://issues.apache.org/jira/browse/CALCITE-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18142983#comment-18142983
]
Steve Carlin commented on CALCITE-7925:
---------------------------------------
Ok, reopened the issue.
So my problem is a bit more broad than the simplify. There were deeper issues
and the simplify was doing the right thing.
But, heh, I probably should mention a part of my solution because it's related
to the general problem here.
Many of the methods in RexBuilder are public. And one is allowed to inject
their own RexBuilder into the RelOptCluster. In my implementation, I have a
class that derives from RexBuilder and overrides one of the methods. I call
"super.<x>" which handles the general case, but when it doesn't work, I have my
own implementation for "<x>"
Perhaps the public methods in RexBuilder were only public in order to allow the
Rel* classes to have access. But I am thankful for the extension capability.
And the allowed injection of a RexBuilder allows me to use my methods within
the Calcite internals.
I view RexSimplify in a similar fashion. RexSImplify is a monolith of code
that helps you change (rather than build) a RexNode. And it is designed in a
"all or nothing" type fashion.
As for a solution, I did mention that in my previous post. There is a case
statement within "simplify(RexNode e, RexUnknownAs unknownAs)" that handles
individual situations. If we were able to inject an interface into the
RexSimplify that handles each of those case items, I think that would be a good
place for extensibility. Or, similarly, and slighlty less elegant, allow
extension of all the methods called in that "simplify" call. Not sure if that
solves the other ticket though.
> 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)
