1. 10 Feb, 2005 2 commits
  2. 09 Feb, 2005 11 commits
  3. 08 Feb, 2005 9 commits
    • unknown's avatar
      Fix for BUG#8371: wrong rec_per_key value for hash index on temporary table · 37e2873f
      unknown authored
      
      mysql-test/r/heap_hash.result:
        Testcase for BUG#8371: wrong rec_per_key value for hash index on temporary table
      mysql-test/t/heap_hash.test:
        Testcase for BUG#8371: wrong rec_per_key value for hash index on temporary table
      sql/ha_heap.cc:
        Fix for BUG#8371: wrong rec_per_key value for hash index on temporary table:
        Don't assume that table->rec_per_key==NULL if table->tmp_table != NO_TMP_TABLE, 
        this is not true for tables created with "CREATE TEMPORARY TABLE" (while it holds
        for temporary tables created during query execution)
      sql/sql_select.cc:
        Initialize rec_per_key for all keys in temporary table.
      37e2873f
    • unknown's avatar
      Applied a patch for Netware. · ffe417fd
      unknown authored
      ffe417fd
    • unknown's avatar
      Merge tulin@bk-internal.mysql.com:/home/bk/mysql-4.1 · 0f320e8c
      unknown authored
      into poseidon.ndb.mysql.com:/home/tomas/mysql-4.1
      
      
      0f320e8c
    • unknown's avatar
      Makefile.am: · f899de1d
      unknown authored
        added noinst_HEADERS to get all things for the src dist
      
      
      ndb/test/run-test/Makefile.am:
        added noinst_HEADERS to get all things for the src dist
      f899de1d
    • unknown's avatar
      Merge mysql.com:/home/wax/mysql/mysql-4.1 · 30e89d0a
      unknown authored
      into mysql.com:/home/wax/mysql/mysql-4.1test2
      
      
      30e89d0a
    • unknown's avatar
      Merge jlindstrom@bk-internal.mysql.com:/home/bk/mysql-4.1 · a7325649
      unknown authored
      into hundin.mysql.fi:/home/jan/mysql-4.1
      
      
      a7325649
    • unknown's avatar
      Better bugfix for "HAVING when refering to RAND()" (Bug #8216) · 63982db9
      unknown authored
      Ensure that references in HAVING, ORDER BY or GROUP BY are calculated after fields in SELECT.
      This will ensure that any reference to these has a valid value.
      Generalized the code for split_sum_func()
      
      
      BitKeeper/etc/ignore:
        added support-files/ndb-config-2-node.ini
      mysql-test/r/group_by.result:
        More complicated test to assure that rand() is only calulated once
      mysql-test/r/user_var.result:
        Back to old results :(  (ok but not perfect)
      mysql-test/t/group_by.test:
        More complicated test to assure that rand() is only calulated once
      sql/item.cc:
        Better bugfix for "HAVING when refering to RAND()"
        This will ensure that when refering to things like RAND() in HAVING through an alias we will not recalculate that rand() value in the HAVING part but use the value in the row
        Generalize split_sum_func()
      sql/item.h:
        Better bugfix for "HAVING when refering to RAND()"
        T
      sql/item_cmpfunc.cc:
        Better bugfix for "HAVING when refering to RAND()"
        Use generalized split_sum_func2() function
      sql/item_func.cc:
        Better bugfix for "HAVING when refering to RAND()"
        Use generalized split_sum_func2() function
      sql/item_row.cc:
        Better bugfix for "HAVING when refering to RAND()"
        Use generalized split_sum_func2() function
      sql/item_strfunc.cc:
        Better bugfix for "HAVING when refering to RAND()"
        Use generalized split_sum_func2() function
      sql/sql_list.h:
        Add functions to concatenate lists
      sql/sql_select.cc:
        Better bugfix for "HAVING when refering to RAND()"
        Ensure that references in HAVING, ORDER BY or GROUP BY are calculated after fields in SELECT.
        This will ensure that any reference to these has a valid value.
      63982db9
    • unknown's avatar
      Relaxed locking in INSERT...SELECT, single table UPDATE...SELECT and · 6cee60ea
      unknown authored
      single table DELETE...SELECT clauses when innobase_locks_unsafe_for_binlog
      is used and isolation level of the transaction is not serializable. 
      InnoDB uses consistent read in these cases for a selected table.
      Backported from 5.0.x.
      
      
      sql/ha_innodb.cc:
        Relaxed locking in INSERT...SELECT, single table UPDATE...SELECT and 
        single table DELETE...SELECT clauses when innobase_locks_unsafe_for_binlog
        is used and isolation level of the transaction is not serializable. 
        InnoDB uses consistent read in these cases for a selected table.
      6cee60ea
    • unknown's avatar
      6a1e7562
  4. 07 Feb, 2005 17 commits
  5. 06 Feb, 2005 1 commit