On Sun, Jan 25, 2015 at 08:54:11PM +0100, Sergei Golubchik wrote: > 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). >
Yes, agree. BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
