• unknown's avatar
    Fix LP BUG#613029 · 7999f40a
    unknown authored
    Analysis:
    There are two code paths through which JOIN::exec may produce
    an all-NULL row for an empty result set. One goes via the
    function return_zero_rows(), when query processing detectes
    early that the where clause is false, the other one is via
    do_select() in the case of join execution.
    
    In the case of do_select(), the problem was that the executioner
    didn't set TABLE::null_row to 1. As result when sending the only
    result row, the evaluation of each field didn't detect that all
    non-aggregated fields are NULL, because Field::is_null returned
    true, after checking that field->table->null_row was false.
    
    Given that the each non-aggregated field was not considered NULL,
    select_result::send_data sent whatever was in the buffer of each
    field. However, since there was no actual data in the field buffer,
    send_data() accessed and sent whatever junk was in the field's
    data buffer.
    
    Solution:
    Similar to the analogous case in return_zero_rows() mark all
    tables that their current row is NULL before sending the
    artificailly created NULL row.
    7999f40a
subselect4.result 47.5 KB