Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <77809.1173977709538.JavaMail.jira@brutus>
Date: Thu, 15 Mar 2007 09:55:09 -0700 (PDT)
From: "A B (JIRA)" <jira@apache.org>
To: derby-dev@db.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
In-Reply-To: <1503805749.1131051224607.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

A B commented on DERBY-681:
---------------------------

Thank you for the follow-up patch, Manish.  I verified that "followup.patch.txt" solves the problem I reported above, so I committed the patch after adding a corresponding test case to lang/subquery.sql (always good to have a regression test case when possible):

    URL: http://svn.apache.org/viewvc?view=rev&rev=518687

I assume that the numGeneratedColumnsForGroupBy() method, which is now no longer in use, will be removed as part of your work for DERBY-2442?

> 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, 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.