[
https://issues.apache.org/jira/browse/DERBY-3257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-3257:
----------------------------------
Attachment: derby-3257_diff2.txt
Thanks Army for looking at the patch.
Attached is a revised patch derby-3257_diff2.txt with the changes you
recommended. I will commit this afternoon if I don't hear anything back.
You asked
>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?
Flattenning produces a column in the having clause that is not generated to
replace an aggregate causing this condition to throw the exception:
if (!cr.getGeneratedToReplaceAggregate() &&
cr.getSourceLevel() == level) {
throw StandardException.newException(
SQLState.LANG_INVALID_COL_HAVING_CLAUSE,
cr.getSQLColumnName());
}
I tried to understand why this condition was necessary by commenting it out and
I ended up with a null pointer exception in the generated code when I had a
select in the having clause. I didn't pursue it much further than that and
figured Manish put that condition and error there for good reason. Perhaps
there is a way to allow the flattenning of the subquery but I was not able to
figure out how to do it so went with this solution.
I'm hoping at some point. Manish or someone else can take a look at this and
come up with a more elegant solution allowing the subqueries to be flattenned
in the having clause.
> 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_diff2.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.
