[ 
https://issues.apache.org/jira/browse/DERBY-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561065#action_12561065
 ] 

A B commented on DERBY-3257:
----------------------------

Thank you for investigating this further, and for posting a complete patch, 
Kathey.  I verified that the new test case passes with the changes and fails 
without them.

> We clearly are not setup to handle subquery flattenning within the having 
> clause

This is good to know.  Just curious: is there something in the code that makes 
this limitation explicit, or does this statement just follow from the fact that 
attempts to flatten such a subquery lead to other errors?

Very minor nits on the patch that you can ignore if you choose:

  - Might be good to add another bullet to the list in the comment preceding 
the following
    line, so that the comments and the code match each other.

        @@ -609,7 +615,7 @@
        -            underTopAndNode &&
        +           underTopAndNode && !havingSubquery &&

    Likewise for the other, similar change further down in that method.

  - Some whitespace inconsistencies between new code and existing code.

  - Maybe the new test case in GroupByTest would be better called 
"testOrNodeInHavingClause()"
    instead of "testDerby3257?"  This doesn't affect the test at all, and the 
comments for the fixture
    clearly indicate what is being tested, so this is definitely "nit-picking". 
 But a meaningful method
    name seems (to me, as reader of the test) slightly more convenient than the 
Derby Jira number.

But these nits aside, if you've run derbyall and suites.All with this change 
and there were no failures, I think the patch can be committed...

> SELECT with HAVING clause containing OR conditional incorrectly return 1 row 
> - should return 2 rows - works correctly with 10.2 DB
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3257
>                 URL: https://issues.apache.org/jira/browse/DERBY-3257
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.3.1.4, 10.3.2.1, 10.4.0.0
>            Reporter: Stan Bradbury
>            Assignee: Kathey Marsden
>         Attachments: 42X24_error.sql, d3257_doNOTCommit.patch, 
> derby-3257_diff.txt, derby-3257_plan_10.2.txt, derby-3257_plan_10.4.txt, 
> derby-3257_stat.txt, TestHaving.java
>
>
> Attached program demonstrates the problem.  Only one count is returned 
> (matching CODE= GBR) - the count of CODE=CHA is not returned.  Works fine 
> with versions 10.1 and 10.2 or if program is run using 10.3 jars and 10.2 
> database (soft upgrade).
> Query:
> SELECT COUNT(t0.ID) FROM CTS1.TEST_TABLE t0 
>   GROUP BY t0.CODE 
>     HAVING (t0.CODE = 'GBR' OR t0.CODE = 'CHA') AND t0.CODE IS NOT NULL
> Incorrect results (see last line):
> Database product: Apache Derby
> Database version: 10.3.1.5 - (579866)
> Driver name:      Apache Derby Embedded JDBC Driver
> Driver version:   10.3.1.5 - (579866)
> result: 2
> Correct results:
> Database product: Apache Derby
> Database version: 10.2.2.0 - (485682)
> Driver name:      Apache Derby Embedded JDBC Driver
> Driver version:   10.2.2.0 - (485682)
> result: 4
> result: 2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to