Derby
  1. Derby
  2. DERBY-4410

NullPointerException when USING clause contains all columns in both join tables

    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> create table t(x int);
      0 rows inserted/updated/deleted
      ij> select t1., t2. from t t1 join t t2 using ;
      ERROR XJ001: Java exception: ': java.lang.NullPointerException'.

      This statement should have raised an exception because both t1.* and t2.* expand to no columns. See DERBY-4407.

      1. adjustIndexWithTest.diff
        2 kB
        Knut Anders Hatlen
      2. adjustIndex.diff
        1 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          The problem appears to be the logic in ResultColumnList.expandAllsAndNameColumns(). It goes through the RCL, removes the asterisks in the list and inserts the columns that the asterisks should expand to. However, it does not adjust the index variable when it removes and adds elements in the middle of the very same list that it's iterating over. When the asterisk expands to more than one column, this makes the loop waste time on looking for result columns to expand inside the list of already expanded columns, but it doesn't actually cause any harm. However, if it expands to an empty column list, the loop will skip the next element in the RCL because the current list element was removed without decrementing the index accordingly.

          This makes the statement in the bug description fail because t2.* is never expanded, and it therefore fails with a NullPointerException later when the RCL is processed by code that expect all such columns to have been expanded.

          Show
          Knut Anders Hatlen added a comment - The problem appears to be the logic in ResultColumnList.expandAllsAndNameColumns(). It goes through the RCL, removes the asterisks in the list and inserts the columns that the asterisks should expand to. However, it does not adjust the index variable when it removes and adds elements in the middle of the very same list that it's iterating over. When the asterisk expands to more than one column, this makes the loop waste time on looking for result columns to expand inside the list of already expanded columns, but it doesn't actually cause any harm. However, if it expands to an empty column list, the loop will skip the next element in the RCL because the current list element was removed without decrementing the index accordingly. This makes the statement in the bug description fail because t2.* is never expanded, and it therefore fails with a NullPointerException later when the RCL is processed by code that expect all such columns to have been expanded.
          Hide
          Knut Anders Hatlen added a comment -

          The attached patch appears to fix the problem. It changes the loop so that the index is adjusted after elements have been removed from or added to the RCL. This should fix both the harmless double processing and the problematic skipping of elements.

          The patch does not include a regression test, and none of the existsing regression tests have been run yet.

          Show
          Knut Anders Hatlen added a comment - The attached patch appears to fix the problem. It changes the loop so that the index is adjusted after elements have been removed from or added to the RCL. This should fix both the harmless double processing and the problematic skipping of elements. The patch does not include a regression test, and none of the existsing regression tests have been run yet.
          Hide
          Bryan Pendleton added a comment -

          Great find! I remember stepping through this code once and noticing that it
          re-processed the columns after expanding them, but it had never occurred
          to me that it would have this behavior if the * expanded to an empty set.

          Fix looks fine to me, and the comment is quite useful thanks. But maybe the
          indentation looks off (spaces vs tabs?)

          Show
          Bryan Pendleton added a comment - Great find! I remember stepping through this code once and noticing that it re-processed the columns after expanding them, but it had never occurred to me that it would have this behavior if the * expanded to an empty set. Fix looks fine to me, and the comment is quite useful thanks. But maybe the indentation looks off (spaces vs tabs?)
          Hide
          Knut Anders Hatlen added a comment -

          Thanks for looking at the patch, Bryan!

          Regarding the current behaviour, also note that it doesn't re-process all the expanded columns, it always skips the first one in the expanded list, which also suggests that the re-processing of the rest of the columns is unnecessary.

          I'm uploading a new patch which changes the space indentation in RCL to tabs and adds a test case in JoinTest. All the regression tests ran cleanly.

          Show
          Knut Anders Hatlen added a comment - Thanks for looking at the patch, Bryan! Regarding the current behaviour, also note that it doesn't re-process all the expanded columns, it always skips the first one in the expanded list, which also suggests that the re-processing of the rest of the columns is unnecessary. I'm uploading a new patch which changes the space indentation in RCL to tabs and adds a test case in JoinTest. All the regression tests ran cleanly.
          Hide
          Knut Anders Hatlen added a comment -

          Committed revision 829034.

          Show
          Knut Anders Hatlen added a comment - Committed revision 829034.

            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