db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-681) Eliminate the parser's rewriting of the abstract syntax tree for queries with GROUP BY and/or HAVING clauses
Date Tue, 13 Feb 2007 16:42:05 GMT

    [ https://issues.apache.org/jira/browse/DERBY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472754

A B commented on DERBY-681:

Manish Khettry (JIRA) wrote:
> Thanks for reviewing the patch. It will take me sometime to make
> the patch current and look at your comments. It has, after all, 
> been a while since I submitted the patch.

Thank you for willingness to continue working with the patch.

> I am curious-- is it typical for a patch to gather dust for a 
> few months before someone finds the time to look at it?

I don't think it's "typical" for this to happen, no.  But given the "fry your own fish" philosophy
of open source development, this kind of thing does (unfortunately) happen on occasion.

The derby-dev mailing list receives a daily "subscription" email which lists issues having
the "Patch Available" flag set.  The issues are sorted according to the date of that last
update/comment; those at the bottom of the list are the ones that have been sitting the longest
with no activity.  Ex.:


That said, though, it's up to people in the community (users, developers, anyone--doesn't
just have to be committers) to review patches and/or comment on the various issues according
to their own interest/expertise.  And as you've seen, sometimes the result is that things
slip through the cracks.

I noticed DERBY-681 at the bottom of the list last week, which is what prompted me to look
it up--and in doing so I saw that it had been idle for two months(!).  So as I mentioned in
my previous comment, I am willing to work with you on this patch so that it can now be committed.
 Apologies for the awfully long delay...

It's definitely not a good thing to have patches sitting for so long without review.  While
the decision as to who reviews what patches is entirely up to those in the community, you
should feel free to "push" your patch if it's not getting any attention.  See "Extra Mile"
advice on the wiki:


And in particular, note the following quote:

"Post to the list at least every couple of weeks if you don't get review. Ask if someone is
available to look at your patch and what additional information reviewers might need for review."

I have found that sending an explicit email to derby-dev asking for people to review a patch
which has been idle for a couple of weeks almost always leads to a reply and a subsequent
review.  So feel free to do so!

> 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
>         Assigned To: Manish Khettry
>         Attachments: 681.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.

View raw message