1. 21 May, 2007 1 commit
  2. 16 May, 2007 1 commit
  3. 12 May, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #28375: a query with an NOT IN subquery predicate may cause · 11d5f7ee
      igor@olga.mysql.com authored
      a crash when the left operand of the predicate is evaluated to NULL.
      It happens when the rows from the inner tables (tables from the subquery)
      are accessed by index methods with key values obtained by evaluation of
      the left operand of the subquery predicate. When this predicate is
      evaluated to NULL an alternative access with full table scan is used
      to check whether the result set returned by the subquery is empty or not.
      The crash was due to the fact the info about the access methods used for
      regular key values was not properly restored after a switch back from the
      full scan access method had occurred.
      The patch restores this info properly.
      The same problem existed for queries with IN subquery predicates if they
      were used not at the top level of the queries.
      11d5f7ee
  4. 11 May, 2007 8 commits
  5. 10 May, 2007 3 commits
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #28000. · 848f56b0
      gshchepa/uchum@gleb.loc authored
      Bug occurs in INSERT IGNORE ... SELECT ... ON DUPLICATE KEY UPDATE
      statements, when SELECT returns duplicated values and UPDATE clause
      tries to assign NULL values to NOT NULL fields.
      NOTE: By current design MySQL server treats INSERT IGNORE ... ON
      DUPLICATE statements as INSERT ... ON DUPLICATE with update of
      duplicated records, but MySQL manual lacks this information.
      After this fix such behaviour becomes legalized.
      
      The write_record() function was returning error values even within
      INSERT IGNORE, because ignore_errors parameter of
      the fill_record_n_invoke_before_triggers() function call was
      always set to FALSE. FALSE is replaced by info->ignore.
      848f56b0
    • igor@olga.mysql.com's avatar
      Fixed bug #28189: in some rare cases optimizer preferred a more expensive · 53888b42
      igor@olga.mysql.com authored
      ref access to a less expensive range access. 
      This occurred only with InnoDB tables.
      53888b42
    • holyfoot/hf@mysql.com/hfmain.(none)'s avatar
      bug 27921 (Views ignore precision for CAST) · d535add0
      holyfoot/hf@mysql.com/hfmain.(none) authored
      test result fixed
      d535add0
  6. 09 May, 2007 3 commits
  7. 08 May, 2007 2 commits
    • evgen@moonbone.local's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt · b45ef06e
      evgen@moonbone.local authored
      into  moonbone.local:/mnt/gentoo64/work/27670-bug-5.0-opt-mysql
      b45ef06e
    • evgen@moonbone.local's avatar
      Bug#27670: LOAD DATA does not set CURRENT_TIMESTAMP default value for a · 98fa542a
      evgen@moonbone.local authored
      TIMESTAMP field when no value has been provided.
      
      The LOAD DATA sets the current time in the TIMESTAMP field with
      CURRENT_TIMESTAMP default value when the field is detected as a null.
      But when the LOAD DATA command loads data from a file that doesn't contain
      enough data for all fields then the rest of fields are simply set to null
      without any check. This leads to no value being inserted to such TIMESTAMP
      field.
      
      Now the read_sep_field() and the read_fixed_length() functions set current
      time to the TIMESTAMP field with CURRENT_TIMESTAMP default value in all cases
      when a NULL value is loaded to the field.
      98fa542a
  8. 07 May, 2007 12 commits
  9. 04 May, 2007 9 commits