Hi Sanja and Igor, Can you please help to understand this pieces of code in sql_select.cc in 10.0:

else if (cond->type() == Item::FUNC_ITEM || cond->real_item()->type() == Item::FIELD_ITEM) {

It seems that the "cond->real_item()->type() == Item::FIELD_ITEM" part of this condition is a dead code. I added a DBUG_ASSERT in the very beginning of this block, like this:

else if (cond->type() == Item::FUNC_ITEM || cond->real_item()->type() == Item::FIELD_ITEM) { DBUG_ASSERT(cond->real_item()->type() != Item::FIELD_ITEM);

and run all tests. Nothing crashed. I suspect that the following scenario could happen: 1. In April 2011 Igor fixed bugs #717577, #724942 with this commit:

commit 8d9dd21d85e257051b45b2f779dcd9bf696bf9e1 Author: Igor Babaev <igor@askmonty.org> Wed Apr 27 06:58:41 2011 Committer: Igor Babaev <igor@askmonty.org> Wed Apr 27 06:58:41 2011

Fixed LP bugs #717577, #724942.

and this line was probably to handle conditions like "WHERE field". 2. In July 2011 Sanja introduced a new function normalize_cond(), with this commit:

commit 20a2e1d0ac46e375ee7246576b541624c6f8f028 Author: unknown <sanja@askmonty.org> Thu Jul 21 11:20:55 2011 unknown <sanja@askmonty.org> Thu Jul 21 11:20:55 2011

so all conditions "WHERE/HAVING field" are now replaced to "WHERE/HAVING field<>0". So now, by the time of a build_equal_items_for_cond() call all conditions are already replaced and no FIELD_ITEM are actually possible. Can you please confirm this? If my guess is correct then this part can now be safely removed:

|| cond->real_item()->type() == Item::FIELD_ITEM

Thanks.