bzr push into mysql-5.0-bugteam branch (joro:2732 to 2733)

[Georgi Kodinov]

 2733 Georgi Kodinov	2009-01-29 [merge]
      merged 35396 to 5.0-bugteam
      modified:
        sql/sql_parse.cc

 2732 Gleb Shchepa	2009-01-28
      Bug #39069: <row constructor> IN <table-subquery> seriously
                  messed up
      
      "ROW(...) IN (SELECT ... FROM DUAL)" always returned TRUE.
      
      Item_in_subselect::row_value_transformer rewrites "ROW(...)
      IN SELECT" conditions into the "EXISTS (SELECT ... HAVING ...)"
      form.
      For a subquery from the DUAL pseudotable resulting HAVING
      condition is an expression on constant values, so further
      transformation with optimize_cond() eliminates this HAVING
      condition and resets JOIN::having to NULL.
      Then JOIN::exec treated that NULL as an always-true-HAVING
      and that caused a bug.
      
      To distinguish an optimized out "HAVING TRUE" clause from
      "HAVING FALSE" we already have the JOIN::having_value flag.
      However, JOIN::exec() ignored JOIN::having_value as described
      above as if it always set to COND_TRUE.
      
      The JOIN::exec method has been modified to take into account
      the value of the JOIN::having_value field.
      modified:
        mysql-test/r/subselect3.result
        mysql-test/t/subselect3.test
        sql/sql_select.cc

=== modified file 'sql/sql_parse.cc'
--- a/sql/sql_parse.cc	2009-01-15 10:48:31 +0000
+++ b/sql/sql_parse.cc	2009-01-29 12:40:48 +0000
@@ -2333,8 +2333,9 @@ void log_slow_statement(THD *thd)
   {
     thd->proc_info="logging slow query";
 
-    if ((ulong) (thd->start_time - thd->time_after_lock) >
-	thd->variables.long_query_time ||
+    if ((thd->start_time > thd->time_after_lock && 
+         (ulong) (thd->start_time - thd->time_after_lock) >
+	thd->variables.long_query_time) ||
         (thd->server_status &
 	  (SERVER_QUERY_NO_INDEX_USED | SERVER_QUERY_NO_GOOD_INDEX_USED)) &&
         opt_log_queries_not_using_indexes &&