You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Bryan Pendleton (JIRA)" <ji...@apache.org> on 2007/01/10 21:35:27 UTC

[jira] Updated: (DERBY-1861) Column ordering ASSERT when combining column references and expressions in same ORDER BY

     [ https://issues.apache.org/jira/browse/DERBY-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Pendleton updated DERBY-1861:
-----------------------------------

    Derby Info:   (was: [Patch Available])

Thanks much Yip and Army for the reviews and suggestions.

I'm intending to investigate the issues that Army noted, but I probably won't
get to it for a little while. Depending on what I find, I'll either come back with
a revised patch, or proceed with this patch.


> Column ordering ASSERT when combining column references and expressions in same ORDER BY
> ----------------------------------------------------------------------------------------
>
>                 Key: DERBY-1861
>                 URL: https://issues.apache.org/jira/browse/DERBY-1861
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.3.0.0
>            Reporter: Bryan Pendleton
>         Assigned To: Bryan Pendleton
>            Priority: Minor
>         Attachments: adjustOffsets_v1.diff, dataStructureNotes.html, proposedPatchNotes.html
>
>
> An ORDER BY clause wihch combines both column references and expressions causes the
> sort engine to throw an ASSERT failure in sane builds.
> Here's a repro script:
> -bash-2.05b$ java org.apache.derby.tools.ij
> ij version 10.3
> ij> connect 'jdbc:derby:brydb;create=true';
> ij> create table t (a int, b int, c int, d int);
> 0 rows inserted/updated/deleted
> ij> insert into t values (1, 2, 3, 4);
> 1 row inserted/updated/deleted
> ij> select * from t order by a, b, c+2;
> ERROR XJ001: Java exception: 'ASSERT FAILED column ordering error: org.apache.derby.shared.common.sanity.AssertFailure'.
> As a first theory to check, I believe that when columns in the ORDER BY clause go through "pullup" processing,
> they are generated into the select statement's ResultColumnList and then are later removed at bind time because
> they are determined to duplicate the columns implicitly selected by the "*" column list. But the expression "c+2" is not
> removed from the result list because it does not duplicate any existing column in the table. During this processing,
> I think that the field "addedColumnOffset" in class OrderByColumn is not managed correctly and ends up generating
> a bogus column position for the "c+2" column (it doesn't reflect that pulled-up columns "a" and "b" have disappeared
> from the ResultColumnList), causing the sanity assertion at execution time.
> I stumbled across this problem while writing regression tests for DERBY-147, but the problem occurs
> with or without the DERBY-147 fix, so I decided to log it as a separate problem.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira