Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.8.2.2
    • Fix Version/s: 10.9.1.0
    • Component/s: Documentation
    • Labels:
      None
    1. DERBY-5506.diff
      2 kB
      Kim Haase
    2. DERBY-5506.stat
      0.1 kB
      Kim Haase
    3. DERBY-5506.zip
      6 kB
      Kim Haase

      Activity

      Hide
      Kim Haase added a comment -

      It appears that the only change that would be required would be to remove the following sentence from the TableSubquery topic in the Reference Manual:

      "When used with EXISTS, it returns multiple columns only if you use * to return the multiple columns."

      It might be helpful, though, to add an example of the use of EXISTS without an asterisk.

      Show
      Kim Haase added a comment - It appears that the only change that would be required would be to remove the following sentence from the TableSubquery topic in the Reference Manual: "When used with EXISTS, it returns multiple columns only if you use * to return the multiple columns." It might be helpful, though, to add an example of the use of EXISTS without an asterisk.
      Hide
      Knut Anders Hatlen added a comment -

      Maybe an example that doesn't use asterisk would be helpful, but I don't think that example should use multiple columns. Although such queries are allowed now, I don't think there's any reason why a user would write such a query (more typing for the exact same behaviour), so there's no reason for us to encourage it through an example.(The motivation for supporting the syntax was that some machine-generated SQL contained multiple columns in the EXISTS query.)

      I suppose that in addition to removing the above mentioned sentence from the TableSubquery topic, we should also adjust the preceding sentence to "When used as a TableExpression in a FROM clause, or with EXISTS, it can return multiple columns."

      Show
      Knut Anders Hatlen added a comment - Maybe an example that doesn't use asterisk would be helpful, but I don't think that example should use multiple columns. Although such queries are allowed now, I don't think there's any reason why a user would write such a query (more typing for the exact same behaviour), so there's no reason for us to encourage it through an example.(The motivation for supporting the syntax was that some machine-generated SQL contained multiple columns in the EXISTS query.) I suppose that in addition to removing the above mentioned sentence from the TableSubquery topic, we should also adjust the preceding sentence to "When used as a TableExpression in a FROM clause, or with EXISTS, it can return multiple columns."
      Hide
      Kim Haase added a comment -

      Thanks for the advice on this, Knut. I found that I needed to modify not only the table subquery topic, but also the Boolean expressions topic, where EXISTS is documented as a Boolean operator.

      Attaching DERBY-5506.diff, DERBY-5506.stat, and DERBY-5506.zip, with these changes:

      M src/ref/rreftablesubquery.dita
      M src/ref/rrefsqlj23075.dita

      Show
      Kim Haase added a comment - Thanks for the advice on this, Knut. I found that I needed to modify not only the table subquery topic, but also the Boolean expressions topic, where EXISTS is documented as a Boolean operator. Attaching DERBY-5506 .diff, DERBY-5506 .stat, and DERBY-5506 .zip, with these changes: M src/ref/rreftablesubquery.dita M src/ref/rrefsqlj23075.dita
      Hide
      Knut Anders Hatlen added a comment -

      The patch looks good to me. +1 to commit.

      Show
      Knut Anders Hatlen added a comment - The patch looks good to me. +1 to commit.
      Hide
      Kim Haase added a comment -

      Thanks, Knut!

      Committed patch DERBY-5506.diff to documentation trunk at revision 1325753.

      Seems if I do a commit between 9 and 9:30 am Eastern time, the commit email goes into some sort of black hole. With afternoon commits I get the message right away. Odd.

      Show
      Kim Haase added a comment - Thanks, Knut! Committed patch DERBY-5506 .diff to documentation trunk at revision 1325753. Seems if I do a commit between 9 and 9:30 am Eastern time, the commit email goes into some sort of black hole. With afternoon commits I get the message right away. Odd.
      Hide
      Kim Haase added a comment -

      Changes have appeared in Latest Alpha Manuals.

      Show
      Kim Haase added a comment - Changes have appeared in Latest Alpha Manuals.
      Hide
      Kim Haase added a comment -

      Reopening to add fix version.

      Show
      Kim Haase added a comment - Reopening to add fix version.
      Hide
      Kim Haase added a comment -

      Fix version added.

      Show
      Kim Haase added a comment - Fix version added.

        People

        • Assignee:
          Kim Haase
          Reporter:
          Dag H. Wanvik
        • Votes:
          0 Vote for this issue
          Watchers:
          1 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development