1. 09 Dec, 2007 2 commits
  2. 08 Dec, 2007 4 commits
    • igor@olga.mysql.com's avatar
      Merge olga.mysql.com:/home/igor/mysql-5.0-opt · be5485ce
      igor@olga.mysql.com authored
      into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug32815
      be5485ce
    • timour/tkatchaounov@lapi.mysql.com's avatar
      Fix for BUG#32694 "NOT NULL table field in a subquery produces invalid results" · 9be915e7
      timour/tkatchaounov@lapi.mysql.com authored
        
      The problem was that when convert_constant_item is called for subqueries,
      this happens when we already started executing the top-level query, and
      the field argument of convert_constant_item pointed to a valid table row.
      In turn convert_constant_item used the field buffer to compute the value
      of its item argument. This copied the item's value into the field,
      and made equalities with outer references always true.
        
      The fix saves/restores the original field's value when it belongs to an
      outer table.
      9be915e7
    • igor@olga.mysql.com's avatar
      Fixed bug #27545. · c04d3727
      igor@olga.mysql.com authored
      Both arguments of the function NAME_CONST must be constant expressions.
      This constraint is checked in the Item_name_const::fix_fields method. 
      Yet if the argument of the function was not a constant expression no
      error message was reported. As a result the client hanged waiting for a
      response.
      Now the function Item_name_const::fix_fields reports an error message
      when any of the additional context conditions imposed on the function
      NAME_CONST is not satisfied. 
      c04d3727
    • igor@olga.mysql.com's avatar
      Fixed bug #32815. · c394dbe1
      igor@olga.mysql.com authored
      The index (key_part_1, key_part-2) was erroneously considered as compatible
      with the required ordering in the function test_test_if_order_by_key when 
      a query with an ORDER BY clause contained a condition of the form
        key_part_1=const OR key_part_1 IS NULL 
      and the order list contained only key_part_2. This happened because the value
      of the const_key_parts field in the KEYUSE structure was not formed correctly
      for the keys that could be used for ref_or_null access. 
      This was fixed in the code of the update_ref_and_keys function.
      The problem could not manifest itself for MyISAM databases because the
      implementation of the keys_to_use_for_scanning() handler function always
      returns an empty bitmap for the MyISAM engine.
      c394dbe1
  3. 06 Dec, 2007 2 commits
  4. 04 Dec, 2007 1 commit
  5. 03 Dec, 2007 2 commits
  6. 02 Dec, 2007 1 commit
  7. 01 Dec, 2007 5 commits
  8. 30 Nov, 2007 8 commits
  9. 29 Nov, 2007 2 commits
  10. 27 Nov, 2007 6 commits
  11. 26 Nov, 2007 7 commits
    • kaa@polly.(none)'s avatar
      Merge polly.(none):/home/kaa/src/opt/bug28837/my50-bug29131 · e854d43a
      kaa@polly.(none) authored
      into  polly.(none):/home/kaa/src/opt/mysql-5.0-opt
      e854d43a
    • kaa@polly.(none)'s avatar
      Fix for bug #28837: MyISAM storage engine error (134) doing delete with · 8fdd9087
      kaa@polly.(none) authored
      self-join
      
      When doing DELETE with self-join on a MyISAM or MERGE table, it could
      happen that a record being retrieved in join_read_next_same() has
      already been deleted by previous iterations. That caused the engine's
      index_next_same() method to fail with HA_ERR_RECORD_DELETED error and
      the whole DELETE query to be aborted with an error.
      
      Fixed by suppressing the HA_ERR_RECORD_DELETED error in
      hy_myisam::index_next_same() and ha_myisammrg::index_next_same(). Since
      HA_ERR_RECORD_DELETED can only be returned by MyISAM, there is no point
      in filtering this error in the SQL layer.
      8fdd9087
    • kaa@polly.(none)'s avatar
      5.0 version of the fix for bug #9481: mysql_insert_id() returns 0 after · 24c9d864
      kaa@polly.(none) authored
      insert ... select.
      
      The 5.0 manual page for mysql_insert_id() does not mention anything
      about INSERT ... SELECT, though its current behavior is incosistent
      with what the manual says about the plain INSERT.
      
      Fixed by changing the AUTO_INCREMENT and mysql_insert_id() handling
      logic in INSERT ... SELECT to be consistent with the INSERT behavior,
      the manual, and the changes in 5.1 introduced by WL3146:
      
      
      - mysql_insert_id() now returns the first automatically generated
      AUTO_INCREMENT value that was successfully inserted by INSERT ... SELECT
      
      -  if an INSERT ... SELECT statement is executed, and no automatically
      generated value is successfully inserted, mysql_insert_id() now returns
      the ID of the last inserted row.
      24c9d864
    • gkodinov/kgeorge@magare.gmz's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 30c9f943
      gkodinov/kgeorge@magare.gmz authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B32036-5.0-opt
      30c9f943
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      Bug #31900 Wrong confusing comment in mysql_com.h header file. · 68c60314
      holyfoot/hf@mysql.com/hfmain.(none) authored
      comment fixed as we truly need const_item to be 1 to mark
      constant function
      68c60314
    • gkodinov/kgeorge@magare.gmz's avatar
      Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · 6008aa21
      gkodinov/kgeorge@magare.gmz authored
      into  magare.gmz:/home/kgeorge/mysql/autopush/B32036-5.0-opt
      6008aa21
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #32036: EXISTS within a WHERE clause with a UNION · 55afc5c2
      gkodinov/kgeorge@magare.gmz authored
        crashes MySQL 5.122
      There was a difference in how UNIONs are handled
      on top level and when in sub-query.
      Because the rules for sub-queries were syntactically
      allowing cases that are not currently supported by
      the server we had crashes (this bug) or wrong results
      (bug 32051).
      Fixed by making the syntax rules for UNIONs match the 
      ones at top level.
      
      These rules however do not support nesting UNIONs, e.g.
      (SELECT a FROM t1 UNION ALL SELECT b FROM t2) 
       UNION
      (SELECT c FROM t3 UNION ALL SELECT d FROM t4)
      Supports for statements with nested UNIONs will be
      added in a future version.
      55afc5c2