[
https://issues.apache.org/jira/browse/CALCITE-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18141273#comment-18141273
]
Steve Carlin commented on CALCITE-7925:
---------------------------------------
It might be in the same area, but it's slightly different from just turning
off. There are three simplifications within simplifyLike, and I do want to use
one of them.
My argument for the community is this: I think the general problem is that
RexSimplify does lots of useful stuff but not all of it is useful to everyone.
Because with this architecture, you're basically saying "You either simplify
these 3500 lines my way that does a lot of individual useful things or you
write your own 3500 lines and copy and paste as you please." If you're forcing
a developer to cut and paste 3500 lines, then the architecture is incorrect,
imo. I've already provided you one use case. I haven't rethought out
CALCITE-7789 so not sure if that is the same problem, but it could be.
I do think that allowing extension is slightly ugly. The RexVisitor stuff may
be interesting, but I'm not sure it will cover this situation. I suppose maybe
what I'm asking for here is an interface that covers each "case" portion in the
"RexNode simplify(RexNode e, RexUnknownAs unknownAs)". Those top level calls
should probably be replaceable, and the top level calls should also be public
in the internal class of Calcite which implements the interface.
I can prolly work on this at some point.
> 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)
