1. 01 Feb, 2009 3 commits
  2. 31 Jan, 2009 8 commits
  3. 30 Jan, 2009 5 commits
  4. 29 Jan, 2009 14 commits
  5. 28 Jan, 2009 10 commits
    • Sergey Petrunia's avatar
      Merge · 0a88026b
      Sergey Petrunia authored
      0a88026b
    • Sergey Petrunia's avatar
      BUG#37822: Correlated subquery with IN and IS UNKNOWN provides wrong result · 24a0651b
      Sergey Petrunia authored
      Item_in_optimizer::is_null() evaluated "NULL IN (SELECT ...)" to NULL regardless of
      whether subquery produced any records, this was a documented limitation.
      
      The limitation has been removed (see bugs 8804, 24085, 24127) now
      Item_in_optimizer::val_int() correctly handles all cases with NULLs. Make
      Item_in_optimizer::is_null() invoke val_int() to return correct values for
      "NULL IN (SELECT ...)".
      
      
      mysql-test/r/subselect.result:
        BUG#37822: Correlated subquery with IN and IS UNKNOWN provides wrong result
        - Testcase
      mysql-test/t/subselect.test:
        BUG#37822: Correlated subquery with IN and IS UNKNOWN provides wrong result
        - Testcase
      24a0651b
    • Gleb Shchepa's avatar
      d2ffbe23
    • Gleb Shchepa's avatar
      Bug #39069: <row constructor> IN <table-subquery> seriously · 39f8dd37
      Gleb Shchepa authored
                  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.
      
      
      mysql-test/r/subselect3.result:
        Added test case for bug #39069.
      mysql-test/t/subselect3.test:
        Added test case for bug #39069.
      sql/sql_select.cc:
        Bug #39069: <row constructor> IN <table-subquery> seriously
                    messed up
        
        The JOIN::exec method has been modified to take into account
        the value of the JOIN::having_value field.
      39f8dd37
    • Davi Arnaut's avatar
      Merge from 5.0-bugteam · 883f734e
      Davi Arnaut authored
      883f734e
    • Magnus Svensson's avatar
      Merge · ef7bce4d
      Magnus Svensson authored
      ef7bce4d
    • Magnus Svensson's avatar
      WL#4189 mtr.pl v2 · fb63a2e3
      Magnus Svensson authored
       - Fix faulty regex used for filtering out suspicious warnings, causing
         warnings/errors from previous tests to be reported
      fb63a2e3
    • Davi Arnaut's avatar
      Remove test case for bug 40264. · 10470974
      Davi Arnaut authored
      Dirty close tricky does not work on Windows.
      
      mysql-test/r/query_cache_notembedded.result:
        Remove test case result.
      mysql-test/t/query_cache_notembedded.test:
        Remove test case.
      10470974
    • Luis Soares's avatar
      Disabled test main.innodb_bug39438: · 6ca1f844
      Luis Soares authored
      BUG#42383 2009-01-28 lsoares 
      "This fails in embedded and on windows. Note that this test is not run 
      on windows and on embedded in PB for main trees currently"
      6ca1f844
    • Georgi Kodinov's avatar
      merged bug 42366 to 5.1-bugteam · 6a25326b
      Georgi Kodinov authored
      6a25326b