1. 19 Jul, 2006 1 commit
  2. 18 Jul, 2006 3 commits
  3. 15 Jul, 2006 1 commit
  4. 14 Jul, 2006 5 commits
  5. 13 Jul, 2006 6 commits
  6. 12 Jul, 2006 4 commits
  7. 11 Jul, 2006 8 commits
  8. 10 Jul, 2006 7 commits
    • evgen@moonbone.local's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-4.1-opt · 4235ab7e
      evgen@moonbone.local authored
      into  moonbone.local:/work/allany-4.1-mysql
      4235ab7e
    • evgen@moonbone.local's avatar
      Fixed bug#16302: Quantified subquery without any tables gives wrong results · d3418971
      evgen@moonbone.local authored
      The ALL/ANY subqueries are the subject of MIN/MAX optimization. The matter
      of this optimization is to embed MIN() or MAX() function into the subquery
      in order to get only one row by which we can tell whether the expression
      with ALL/ANY subquery is true or false.
      But when it is applied to a subquery like 'select a_constant' the reported bug
      occurs. As no tables are specified in the subquery the do_select() function 
      isn't called for the optimized subquery and thus no values have been added 
      to a MIN()/MAX() function and it returns NULL instead of a_constant.
      This leads to a wrong query result.
      
      For the subquery like 'select a_constant' there is no reason to apply
      MIN/MAX optimization because the subquery anyway will return at most one row.
      Thus the Item_maxmin_subselect class is more appropriate for handling such
      subqueries.
      
      The Item_in_subselect::single_value_transformer() function now checks
      whether tables are specified for the subquery. If no then this subselect is
      handled like a UNION using an Item_maxmin_subselect object.
      d3418971
    • gkodinov/kgeorge@macbook.gmz's avatar
      Merge rakia:mysql/4.1/B14553 · 893e9276
      gkodinov/kgeorge@macbook.gmz authored
      into  macbook.gmz:/Users/kgeorge/mysql/work/B14553-4.1-opt
      893e9276
    • gkodinov/kgeorge@mysql.com/rakia.(none)'s avatar
      BUG#14553: NULL in WHERE resets LAST_INSERT_ID · 2c9f5cc7
      To make MySQL compatible with some ODBC applications, you can find
      the AUTO_INCREMENT value for the last inserted row with the following query:
       SELECT * FROM tbl_name WHERE auto_col IS NULL.
      This is done with a special code that replaces 'auto_col IS NULL' with
      'auto_col = LAST_INSERT_ID'.
      However this also resets the LAST_INSERT_ID to 0 as it uses it for a flag
      so as to ensure that only the first SELECT ... WHERE auto_col IS NULL
      after an INSERT has this special behaviour.
      In order to avoid resetting the LAST_INSERT_ID a special flag is introduced
      in the THD class. This flag is used to restrict the second and subsequent
      SELECTs instead of LAST_INSERT_ID.
      2c9f5cc7
    • pekka@orca.ndb.mysql.com's avatar
      4893022e
    • pekka@orca.ndb.mysql.com's avatar
      Merge orca.ndb.mysql.com:/space/pekka/ndb/version/my41 · 6191c7db
      pekka@orca.ndb.mysql.com authored
      into  orca.ndb.mysql.com:/space_old/pekka/ndb/version/my41-bug20847
      6191c7db
    • pekka@orca.ndb.mysql.com's avatar
      Merge pnousiainen@bk-internal.mysql.com:/home/bk/mysql-4.1 · c9db5f80
      pekka@orca.ndb.mysql.com authored
      into  orca.ndb.mysql.com:/space_old/pekka/ndb/version/my41
      c9db5f80
  9. 09 Jul, 2006 1 commit
    • aelkin/elkin@dsl-hkigw8-feb1fb00-100.dhcp.inet.fi's avatar
      BUG#20919 temp tables closing fails when binlog is off · fadbdf27
      closing temp tables through end_thread
      had a flaw in binlog-off branch of close_temporary_tables where
      next table to close was reset via table->next
       for (table= thd->temporary_tables; table; table= table->next)
      which was wrong since the current table instance got destoyed at
      	close_temporary(table, 1);
      
      The fix adapts binlog-on branch method to engage the loop's internal 'next' variable which holds table->next prior table's destoying.
      fadbdf27
  10. 08 Jul, 2006 4 commits