I think this is a duplicate of https://issues.apache.org/jira/browse/CALCITE-1054 <https://issues.apache.org/jira/browse/CALCITE-1054>. In your case, Calcite has noticed that the expression inp9_.intValue() is used twice and has therefore assigned it to a variable before both of the usages. The problem is that both of those usages occur after a null-check on inp9_, whereas the variable declaration + assignment occurs before it.
CALCITE-1054 is a serious issue that keeps hitting us. If you are able to fix that we would be grateful. I don’t recall how close my “proposed fix” in https://github.com/julianhyde/calcite/commits/1066-oracle <https://github.com/julianhyde/calcite/commits/1066-oracle> was to solving the problem, but it’s worth looking at. Julian > On Nov 1, 2017, at 4:18 AM, Roger Shi <[email protected]> wrote: > > Hi all, > > When play with the tutorial dataset, I add one row in table EMPS. The > JOINNDAT values is NULL in that row. By runing the SQL “select YEAR(JOINEDAT) > + MONTH(JOINEDAT) from EMPS”, I get the following error: > > java.lang.NullPointerException > at Baz$1$1.current(Unknown Source) > at > org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.next(Linq4j.java:672) > at > org.apache.calcite.avatica.util.IteratorCursor.next(IteratorCursor.java:46) > at > org.apache.calcite.avatica.AvaticaResultSet.next(AvaticaResultSet.java:239) > at sqlline.IncrementalRows.hasNext(IncrementalRows.java:65) > at sqlline.TableOutputFormat.print(TableOutputFormat.java:33) > at sqlline.SqlLine.print(SqlLine.java:1648) > at sqlline.Commands.execute(Commands.java:834) > at sqlline.Commands.sql(Commands.java:733) > at sqlline.SqlLine.dispatch(SqlLine.java:795) > at sqlline.SqlLine.begin(SqlLine.java:668) > at sqlline.SqlLine.start(SqlLine.java:373) > at sqlline.SqlLine.main(SqlLine.java:265) > > The generated code is: > > return new org.apache.calcite.linq4j.AbstractEnumerable(){ > public org.apache.calcite.linq4j.Enumerator<Long> enumerator() { > return new org.apache.calcite.linq4j.Enumerator<Long>(){ > public final org.apache.calcite.linq4j.Enumerator<Object[]> > inputEnumerator = interpreter.enumerator(); > public void reset() { > inputEnumerator.reset(); > } > > public boolean moveNext() { > return inputEnumerator.moveNext(); > } > > public void close() { > inputEnumerator.close(); > } > > public Object current() { > final Integer inp9_ = (Integer) ((Object[]) > inputEnumerator.current())[9]; > final int v = inp9_.intValue(); > return inp9_ == null ? (Long) null : > Long.valueOf(org.apache.calcite.avatica.util.DateTimeUtils.unixDateExtract(org.apache.calcite.avatica.util.TimeUnitRange.YEAR, > v) + > org.apache.calcite.avatica.util.DateTimeUtils.unixDateExtract(org.apache.calcite.avatica.util.TimeUnitRange.MONTH, > v)); > } > > }; > } > > }; > > The highlight line should be the root cause. The main logic is generated in > org.apache.calcite.adapter.enumerable.RexImpTable#implementNullSemantics. > > It seems the highlight line escapes the null value check. What’s the right > design here? I’d like to have a try to fix it. > > Thanks, > Roger
