Hi, Sergey! On Jan 25, Sergey Petrunia wrote:
Hi Sergei,
== TL;DR == I have debugged that LEFT JOIN problem. The fix is not pretty, but correct. I will now push it into the 10.0 tree.
I've spent few hours in the airport and during the flight debugging it. Agree with the fix, but it needs a better comment - the one that can be understood without few hours of debugging. I suggest: - Do not change the order of testing. Fields may be associated - with a TABLE object without being part of the current row. - For NULL value check to work for these fields, they must - have a valid null_ptr, and this pointer must be checked before - TABLE::null_row. - Note that if a table->null_row is set then also all null_bits are set for the row. + + In the case of the 'result_field' for GROUP BY, table->null_row might + refer to the *next* row in the table (when the algorithm is: read the + next row, see if any of group column values have changed, send the + result - grouped - row to the client if yes). So, table->null_row might + be wrong, but such a result_field is always nullable (that's defined by + original_field->maybe_null()) and we trust its null bit. */ If you agree, I'll commit this change (it doesn't have to be in 10.0.16, of course). Regards, Sergei