Skip to content
  • Roy Lyseng's avatar
    7d4bbada
    Bug#22967439: Mysql 5.7 vs 5.6 incorrect SELECT statement result · 7d4bbada
    Roy Lyseng authored
    The problem here is that an incorrect result is returned for a query
    using a merged derived table or a view when compared to a similar query
    using a base table directly.
    
    The problem cause is within a WHERE condition in a scalar subquery inside
    a HAVING condition of the main query block: A reference to a column from
    the derived table of the outer query block (G_T3.G_F1) returns data from
    the original row buffer of the base table, instead of from the row buffer
    of the temporary table, which should be used since the query is grouped.
    
    The problem lies within Item_field::fix_outer_field(): When a base table
    field is resolved and is within the HAVING clause of a grouped query:
    
              if (!last_checked_context->select_lex->having_fix_field &&
                  select->group_list.elements &&
                  (place == CTX_SELECT_LIST || place == CTX_HAVING))
    
    the Item_field object is wrapped inside an Item_outer_ref object
    which directs the field reference to the temporary table. But when
    a derived table column is resolved, this wrapping does not occur.
    
    The fix is to add similar code for derived table columns as well.
    (Note that the fix is minimal: It only deals with columns from
    HAVING clause, not columns from SELECT list).
    
    A constructor for class Item_outer_ref had to be changed to accept
    Item_ref objects as well as Item_field objects too.
    7d4bbada
    Bug#22967439: Mysql 5.7 vs 5.6 incorrect SELECT statement result
    Roy Lyseng authored
    The problem here is that an incorrect result is returned for a query
    using a merged derived table or a view when compared to a similar query
    using a base table directly.
    
    The problem cause is within a WHERE condition in a scalar subquery inside
    a HAVING condition of the main query block: A reference to a column from
    the derived table of the outer query block (G_T3.G_F1) returns data from
    the original row buffer of the base table, instead of from the row buffer
    of the temporary table, which should be used since the query is grouped.
    
    The problem lies within Item_field::fix_outer_field(): When a base table
    field is resolved and is within the HAVING clause of a grouped query:
    
              if (!last_checked_context->select_lex->having_fix_field &&
                  select->group_list.elements &&
                  (place == CTX_SELECT_LIST || place == CTX_HAVING))
    
    the Item_field object is wrapped inside an Item_outer_ref object
    which directs the field reference to the temporary table. But when
    a derived table column is resolved, this wrapping does not occur.
    
    The fix is to add similar code for derived table columns as well.
    (Note that the fix is minimal: It only deals with columns from
    HAVING clause, not columns from SELECT list).
    
    A constructor for class Item_outer_ref had to be changed to accept
    Item_ref objects as well as Item_field objects too.
Loading