Issue Details (XML | Word | Printable)

Key: CORE-4574
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Adriano dos Santos Fernandes
Reporter: Alex Bekhtin
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Regression: Incorrect result in subquery with aggregate

Created: 09/Oct/14 11:40 AM   Updated: 23/Sep/15 11:30 AM
Component/s: Engine
Affects Version/s: 3.0 Alpha 1
Fix Version/s: 3.0 Beta 1

Environment: Firebird-3.0.0.31355-0_x64

QA Status: Done successfully


 Description  « Hide
with A(ID) as
(
    select 1 from rdb$database
    union all
    select 2 from rdb$database
    union all
    select 3 from rdb$database
),
B(ID1, ID2) as
(
    select 1, null from rdb$database
    union all
    select 2, null from rdb$database
    union all
    select 3, null from rdb$database
)
select
    sum((select count(*) from B where B.ID1 = A.ID))
    ,
    sum((select count(*) from B where B.ID2 = A.ID))
    -- must be (3,0) (FB2.5) , but not (3,3) (FB3.0)
from A

 All   Comments   Change History   Subversion Commits      Sort Order: Descending order - Click to sort in ascending order
Adriano dos Santos Fernandes added a comment - 10/Oct/14 04:02 PM
I'm now calling the super method which should compare all sub nodes.

But I see that in both versions, if the two subselects are identical, it creates two mappings, which seems not obvious nor good for performance.

Dmitry Yemanov added a comment - 09/Oct/14 06:10 PM
Adriano, at the first glance this seemed related to CORE-4084, at least the problem location is the same: RseNode::dsqlMatch.

However, after comparing the node matching code with v2.5, I now wonder why we don't match RSE sub-items anymore? In v2.5, nod_rse->nod_count == 9, so PASS1_node_match is called for the every query element. But v3 checks only dsqlContext and it definitely smells like a regression.

Sean Leyne added a comment - 09/Oct/14 03:12 PM
Please provide an example of the 'real' SQL which is failing. Using a CTE for 'dummy' data, while convenient, can obscure the real issue.

Alex Bekhtin added a comment - 09/Oct/14 01:56 PM
to Sean Leyne

>1- This would appear to be a regression, so that should be reflected in the Subject
Ok. I can't write correct formulation. Correct it please.

> 2- I believe that the Subject of this item should read "Incorrect result using CTE with aggregate" since the issue is with CTE not with subquery functionality.
This CTE for generate example data. This regression is reproduced in the real data.

Sean Leyne added a comment - 09/Oct/14 01:38 PM
1- This would appear to be a regression, so that should be reflected in the Subject

2- I believe that the Subject of this item should read "Incorrect result using CTE with aggregate" since the issue is with CTE not with subquery functionality.