[
https://issues.apache.org/jira/browse/DERBY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710942#action_12710942
]
Kathey Marsden commented on DERBY-681:
--------------------------------------
Well I drilled down on those linked issues and 12 was too harsh. Some of the
linked issues were actually fixed by this change.
The idea of borrowing a query generator from some other project and comparing
results with another db sounds like an interesting one for a new angle on
general testing as well.
It looks like DERBY-4230 is an issue of size() being used where visibleSize()
was appropriate. I seem to recall this being an issue with at least one other
issue. It might be interesting to look at the other size() calls and make sure
they shouldn't be visibleSize() instead now that the rewrite is gone.
A strange thing about Eclipse is when I search for references to
QueryTreeNodeVector.size(), I am getting back all references to a size() method
regardless of the class, which is a quite a lot of references.
> Eliminate the parser's rewriting of the abstract syntax tree for queries with
> GROUP BY and/or HAVING clauses
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-681
> URL: https://issues.apache.org/jira/browse/DERBY-681
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Rick Hillegas
> Assignee: Manish Khettry
> Fix For: 10.3.1.4
>
> Attachments: 681.patch.txt, 681.patch2.txt, 681.patch3.txt,
> followup.patch.txt, notes.txt
>
>
> If a query contains a GROUP BY or HAVING clause, the parser rewrites the
> abstract syntax tree, putting aggregates into a subselect and treating the
> HAVING clause as the WHERE clause of a fabricated outer select from the
> subquery. This allows the compiler to re-use some machinery since the HAVING
> clause operates on the grouped result the way that the WHERE clause operates
> on the from list. Unfortunately, this rewriting creates an explosion of
> special cases in the compiler after parsing is done. The rewriting is not
> systematically handled later on in the compiler. This gives rise to defects
> like bug 280. We need to eliminate this special rewriting and handle the
> HAVING clause in a straightforward way. This is not a small bugfix but is a
> medium sized project.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
