Derby
  1. Derby
  2. DERBY-4414

NullPointerException with JOIN...USING and invalid table name in select list

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.6.1.0
    • Fix Version/s: 10.6.1.0
    • Component/s: SQL
    • Labels:
      None
    • Issue & fix info:
      Repro attached

      Description

      ij version 10.6
      ij> connect 'jdbc:derby:memory:db;create=true';
      ij> create table t(a int, b int, c int);
      0 rows inserted/updated/deleted
      ij> select t.* from t t1 join t t2 using (a);
      ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
      java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:95)
      at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142)
      at org.apache.derby.impl.jdbc.Util.javaException(Util.java:299)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346)
      at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2204)
      at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81)
      at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:614)
      at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555)
      at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:329)
      at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:521)
      at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:363)
      at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:261)
      at org.apache.derby.impl.tools.ij.Main.go(Main.java:229)
      at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:184)
      at org.apache.derby.impl.tools.ij.Main.main(Main.java:75)
      at org.apache.derby.tools.ij.main(ij.java:59)
      Caused by: java.sql.SQLException: Java exception: ': java.lang.NullPointerException'.
      at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(SQLExceptionFactory40.java:119)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:70)
      ... 16 more
      Caused by: java.lang.NullPointerException
      at org.apache.derby.impl.sql.compile.JoinNode.getAllResultColumns(JoinNode.java:431)
      at org.apache.derby.impl.sql.compile.FromList.expandAll(FromList.java:474)
      at org.apache.derby.impl.sql.compile.ResultColumnList.expandAllsAndNameColumns(ResultColumnList.java:1598)
      at org.apache.derby.impl.sql.compile.ResultColumnList.bindExpressions(ResultColumnList.java:686)
      at org.apache.derby.impl.sql.compile.SelectNode.bindExpressions(SelectNode.java:451)
      at org.apache.derby.impl.sql.compile.DMLStatementNode.bindExpressions(DMLStatementNode.java:227)
      at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java:140)
      at org.apache.derby.impl.sql.compile.CursorNode.bindStatement(CursorNode.java:249)
      at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:319)
      at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
      at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:824)
      at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:606)
      ... 9 more

      The query is expected to fail (because the table name in t.* does not match any of the joined tables), but not with a NullPointerException. A similar query with ON instead of USING fails more gracefully:

      ij> select t.* from t t1 join t t2 on t1.a=t2.a;
      ERROR 42X10: 'T' is not an exposed table name in the scope in which it appears.

      1. derby-4414-1a.diff
        3 kB
        Knut Anders Hatlen

        Activity

        Hide
        Knut Anders Hatlen added a comment -

        Committed revision 829041.

        Show
        Knut Anders Hatlen added a comment - Committed revision 829041.
        Hide
        Knut Anders Hatlen added a comment -

        All tests ran cleanly.

        Show
        Knut Anders Hatlen added a comment - All tests ran cleanly.
        Hide
        Knut Anders Hatlen added a comment -

        The USING section of JoinNode.getAllResultColumns() assumed that the table name in an asterisked identifier chain would always be found either in the left child or in the right child of the join. Since it didn't find a match in the left child, it happily went along with the result it got from the right child, which was null and led to a NullPointerException.

        Looking at the other implementations of ResultSetNode.getAllResultColumns(), it is supposed to return null if there is no match. The caller (FromList in this case) will detect that and raise the appropriate error message. The javadoc for RSN.getAllResultColumns() does however not mention that it is OK to return null.

        The attached patch (derby-4414-1a.diff) makes the javadoc in RSN state explicitly that null can be returned and when it can be returned. It also makes JoinNode.getAllResultColumns() do the right thing (return null) when the table name doesn't match any of the sides. And it adds a regression test case to JoinTest.

        I have not run other tests than JoinTest with this patch. I have started the full regression test suite, but JoinTest is the only test that executes joins with a USING clause, so I don't expect any other tests to fail.

        Show
        Knut Anders Hatlen added a comment - The USING section of JoinNode.getAllResultColumns() assumed that the table name in an asterisked identifier chain would always be found either in the left child or in the right child of the join. Since it didn't find a match in the left child, it happily went along with the result it got from the right child, which was null and led to a NullPointerException. Looking at the other implementations of ResultSetNode.getAllResultColumns(), it is supposed to return null if there is no match. The caller (FromList in this case) will detect that and raise the appropriate error message. The javadoc for RSN.getAllResultColumns() does however not mention that it is OK to return null. The attached patch (derby-4414-1a.diff) makes the javadoc in RSN state explicitly that null can be returned and when it can be returned. It also makes JoinNode.getAllResultColumns() do the right thing (return null) when the table name doesn't match any of the sides. And it adds a regression test case to JoinTest. I have not run other tests than JoinTest with this patch. I have started the full regression test suite, but JoinTest is the only test that executes joins with a USING clause, so I don't expect any other tests to fail.

          People

          • Assignee:
            Knut Anders Hatlen
            Reporter:
            Knut Anders Hatlen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development