db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2526) Wrong query results due to column ordering in UNION view
Date Mon, 09 Apr 2007 14:23:32 GMT

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

Bryan Pendleton commented on DERBY-2526:
----------------------------------------

The ResultColumn instance for BVW2.C1 with virtualColumnId = 5
comes from a 9-element ResultColumnList which is built for the
intermediate "table" that is built by JoinNode to represent the
joining of B3 with BVW2. This ResultColumnList has the following columns:
  Name      VirtualColumnId
   b3.c8       1
   b3.c9       2
   b3.c5       3
   b3.c6       4
   bvw2.c1   5
   bvw2.c2   6
   bvw2.c3   7
   bvw2.c4   8
   bvw2.c5   9

In this context, the use of virtualColumnId=5 to represent BVW2.C1 makes complete sense.

So it appears that I can now finally state the problem with some clarity:

The problem involves an inconsistency in the handling of ColumnReference objects
during PredicateList.joinClauseTransitiveClosure. In this code, we are working with
ColumnReference objects whose columnNumber values refer to intermediate join tables,
but the code compares those ColumnReference objects against each other as though
the columnNumber values applied to the base tables.


> Wrong query results due to column ordering in UNION view
> --------------------------------------------------------
>
>                 Key: DERBY-2526
>                 URL: https://issues.apache.org/jira/browse/DERBY-2526
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.0.2.1, 10.1.3.1, 10.2.2.0, 10.3.0.0
>            Reporter: Bryan Pendleton
>         Assigned To: Bryan Pendleton
>         Attachments: badQuery.log, derby-2526.sql, goodQuery.log
>
>
> I think both select statements in the attached repro script should return 1 row, but
in fact the first statement returns 1 row and the second returns zero rows.
> The only difference between the two statements is that the columns in the UNION view
are listed in a different order (bvw vs. bvw2).
> This seems like a bug to me; the order of the columns in the view definition shouldn't
matter, should it? 
> As Army noted on the derby-dev list, the fact that this reproduces with 10.0 means that
it is not caused by some of the 10.2 optimizer changes. Something else is going wrong.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message