I agree with Mihai, mostly. Yes it should be done as a RexNode-to-RexNode mapping.
But hopefully it isn’t a dedicated class that subclasses RexVisitor and just deals with IS NOT TRUE. Each dialect should map calls to operators it does not support to operators that it does support. (I’ve not thought a lot about how that mapping should be defined, but I think it should be declarative — i.e a java.util.Map object somewhere, maybe populated via annotations — as opposed to the rat’s nest of procedural logic.) Currently we deal with that mapping in an ad hoc way, e.g. while generating the SQL string, or with specific methods like SqlDialect.unparseCall, and that’s not good. Julian > On Dec 2, 2024, at 9:52 AM, Mihai Budiu <[email protected]> wrote: > > In general I think it's not a good idea to rely on the front-end of the > compiler giving you a specific shape for the program. > If you want to enforce certain structures you should write code that > implements these structures. > For example, if you do not support IS NOT TRUE, you should write a visitor > that converts IS NOT TRUE to some other form that your target supports. > > Mihai > > ________________________________ > From: udit varshney <[email protected]> > Sent: Sunday, December 1, 2024 9:12 PM > To: [email protected] <[email protected]> > Subject: Need Suggestion on Case expression simplification > > Hi Team, > > I am using the Calcite for materialised view rewrite. I need some > information related to the case expression. Following is the SQL sample- > > *Select upper(c1) as alias1, sum(c2) as alias2 from test where case c3 = > 'A' then false else true end group by 1*. > > Above query is rewritten to- > > *Select upper(c1) as alias1, sum(c2) as alias2 from mv where c3='A' is not > true group by upper(c1)*; > > I tried to check in code and figure out that this conversation is happening > in *RexSimplify* class. > If a query engine doesn't support the *is not true* expression the is there > any way to keep case as it is? > > Thanks, > Udit Kumar
