An error occurred fetching the project authors.
  1. 19 Feb, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #25831: Deficiencies in INSERT ... SELECT ... field name resolving. · d17ad7b3
      gkodinov/kgeorge@macbook.gmz authored
       Several problems fixed: 
        1. There was a "catch-all" context initialization in setup_tables()
          that was causing the table that we insert into to be visible in the 
          SELECT part of an INSERT .. SELECT .. statement with no tables in
          its FROM clause. This was making sure all the under-initialized
          contexts in various parts of the code are not left uninitialized.
          Fixed by removing the "catch-all" statement and initializing the 
          context in the parser.
        2. Incomplete name resolution context when resolving the right-hand
          values in the ON DUPLICATE KEY UPDATE ... part of an INSERT ... SELECT ...
          caused columns from NATURAL JOIN/JOIN USING table references in the
          FROM clause of the select to be unavailable.
          Fixed by establishing a proper name resolution context.
        3. When setting up the special name resolution context for problem 2
          there was no check for cases where an aggregate function without a
          GROUP BY effectively takes the column from the SELECT part of an 
          INSERT ... SELECT unavailable for ON DUPLICATE KEY UPDATE.
          Fixed by checking for that condition when setting up the name 
          resolution context.
      d17ad7b3
  2. 16 Feb, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#16630: The update fields of the INSERT .. SELECT .. ON DUPLICATE KEY · 7916d9e9
      evgen@moonbone.local authored
      UPDATE contains wrong data if the SELECT employs a temporary table.
      
      If the UPDATE values of the INSERT .. SELECT .. ON DUPLICATE KEY UPDATE
      statement contains fields from the SELECT part and the select employs a
      temporary table then those fields will contain wrong values because they
      aren't corrected to get data from the temporary table.
      
      The solution is to add these fields to the selects all_fields list,
      to store pointers to those fields in the selects ref_pointer_array and
      to access them via Item_ref objects.
      
      The substitution for Item_ref objects is done in the new function called 
      Item_field::update_value_transformer(). It is called through the
      item->transform() mechanism at the end of the select_insert::prepare()
      function.
      7916d9e9
  3. 09 Feb, 2007 1 commit
  4. 06 Feb, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#19978: INSERT .. ON DUPLICATE erroneously reports some records were · 96836990
      evgen@moonbone.local authored
      updated.
      
      INSERT ... ON DUPLICATE KEY UPDATE reports that a record was updated when
      the duplicate key occurs even if the record wasn't actually changed
      because the update values are the same as those in the record.
      
      Now the compare_record() function is used to check whether the record was
      changed and the update of a record reported only if the record differs
      from the original one.
      96836990
  5. 22 Jan, 2007 1 commit
  6. 31 Dec, 2006 1 commit
    • kent@mysql.com/kent-amd64.(none)'s avatar
      my_strtoll10-x86.s: · 6523aca7
      kent@mysql.com/kent-amd64.(none) authored
        Corrected spelling in copyright text
      Makefile.am:
        Don't update the files from BitKeeper
      Many files:
        Removed "MySQL Finland AB & TCX DataKonsult AB" from copyright header
        Adjusted year(s) in copyright header 
      Many files:
        Added GPL copyright text
      Removed files:
        Docs/Support/colspec-fix.pl
        Docs/Support/docbook-fixup.pl
        Docs/Support/docbook-prefix.pl
        Docs/Support/docbook-split
        Docs/Support/make-docbook
        Docs/Support/make-makefile
        Docs/Support/test-make-manual
        Docs/Support/test-make-manual-de
        Docs/Support/xwf
      6523aca7
  7. 23 Dec, 2006 1 commit
  8. 11 Dec, 2006 1 commit
  9. 07 Dec, 2006 1 commit
    • kostja@bodhi.local's avatar
      A fix and test cases for · 90072e69
      kostja@bodhi.local authored
      Bug#4968 "Stored procedure crash if cursor opened on altered table"
      Bug#19733 "Repeated alter, or repeated create/drop, fails"
      Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from 
      stored procedure."
      Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing"
      Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server"
      
      Test cases for bugs 4968, 19733, 6895 will be added in 5.0.
      
      Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE 
      statements in stored routines or as prepared statements caused
      incorrect results (and crashes in versions prior to 5.0.25).
      In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE
      SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options).
      
      The problem of bugs 4968, 19733, 19282 and 6895 was that functions
      mysql_prepare_table, mysql_create_table and mysql_alter_table were not
      re-execution friendly: during their operation they used to modify contents
      of LEX (members create_info, alter_info, key_list, create_list),
      thus making the LEX unusable for the next execution.
      In particular, these functions removed processed columns and keys from
      create_list, key_list and drop_list. Search the code in sql_table.cc 
      for drop_it.remove() and similar patterns to find evidence.
      
      The fix is to supply to these functions a usable copy of each of the
      above structures at every re-execution of an SQL statement. 
      
      To simplify memory management, LEX::key_list and LEX::create_list
      were added to LEX::alter_info, a fresh copy of which is created for
      every execution.
      
      The problem of crashing bug 22060 stemmed from the fact that the above 
      metnioned functions were not only modifying HA_CREATE_INFO structure in 
      LEX, but also were changing it to point to areas in volatile memory of 
      the execution memory root.
       
      The patch solves this problem by creating and using an on-stack
      copy of HA_CREATE_INFO (note that code in 5.1 already creates and
      uses a copy of this structure in mysql_create_table()/alter_table(),
      but this approach didn't work well for CREATE TABLE SELECT statement).
      90072e69
  10. 01 Nov, 2006 1 commit
  11. 06 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID. · ee0cebf9
      kroki/tomash@moonlight.intranet authored
      Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored
      procedures.  However, 4.1 had some bugs that were fixed in 5.0 by the
      patch for bug#21726, and this patch is a backport of those fixes.
      Namely, in 4.1 it fixes:
      
        - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific).
      
        - LAST_INSERT_ID() could return the value generated by current
          statement if the call happens after the generation, like in
      
            CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT);
            INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID());
      
        - Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
      ee0cebf9
  12. 02 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID · 5ea8adfa
      kroki/tomash@moonlight.intranet authored
      Non-upper-level INSERTs (the ones in the body of stored procedure,
      stored function, or trigger) into a table that have AUTO_INCREMENT
      column didn't affected the result of LAST_INSERT_ID() on this level.
      
      The problem was introduced with the fix of bug 6880, which in turn was
      introduced with the fix of bug 3117, where current insert_id value was
      remembered on the first call to LAST_INSERT_ID() (bug 3117) and was
      returned from that function until it was reset before the next
      _upper-level_ statement (bug 6880).
      
      The fix for bug#21726 brings back the behaviour of version 4.0, and
      implements the following: remember insert_id value at the beginning
      of the statement or expression (which at that point equals to
      the first insert_id value generated by the previous statement), and
      return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID.
      
      Thus, the value returned by LAST_INSERT_ID() is not affected by values
      generated by current statement, nor by LAST_INSERT_ID(expr) calls in
      this statement.
      
      Version 5.1 does not have this bug (it was fixed by WL 3146).
      5ea8adfa
  13. 28 Sep, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#5505: Wrong error message on INSERT into a view · f6fbbf20
      evgen@moonbone.local authored
      On an INSERT into an updatable but non-insertable view an error message was
      issued stating the view being not updatable. This can lead to a confusion of a
      user.
      
      A new error message is introduced. Is is showed when a user tries to insert
      into a non-insertable view.
      f6fbbf20
  14. 20 Sep, 2006 1 commit
    • istruewing@chilla.local's avatar
      Bug#20830 - INSERT DELAYED does not honour SET INSERT_ID · e9e58c66
      istruewing@chilla.local authored
      Bug#20627 - INSERT DELAYED does not honour auto_increment_* variables
      
      INSERT DELAYED ignored an explicitly set INSERT_ID and session
      specific auto_increment_* variables.
      
      The problem was that the inserts are done by a system thread,
      which does not have access to the session variables of the user
      thread.
      
      On a proposal of Guilhem I fixed it so that the variables are
      copied to the data structure for every delayed row. The system
      thread sets its session variables from these values.
      e9e58c66
  15. 16 Sep, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #21493: crash for the second execution of a function · d3d3cef8
      igor@rurik.mysql.com authored
      containing a select statement that uses an aggregating IN subquery.
      Added a parameter to the function fix_prepare_information 
      to restore correctly the having clause for the second execution.
      Saved andor structure of the having conditions at the proper moment
      before any calls of split_sum_func2 that could modify the having structure
      adding new Item_ref objects. (These additions, are produced not with 
      the statement mem_root, but rather with the execution mem_root.)
      d3d3cef8
  16. 12 Sep, 2006 1 commit
    • timour/timka@lamia.home's avatar
      Fix for BUG#21774: Column count doesn't match value count at row x · 38a450b4
      timour/timka@lamia.home authored
      The cause of the bug was an incomplete fix for bug 18080.
      The problem was that setup_tables() unconditionally reset the
      name resolution context to its 'tables' argument, which pointed
      to the first table of an SQL statement.
      
      The bug fix limits resetting of the name resolution context in
      setup_tables() only in the cases when the context was not set
      by earlier parser/optimizer phases.
      38a450b4
  17. 15 Aug, 2006 1 commit
    • evgen@sunlight.local's avatar
      Fixed bug#21261: Wrong access rights was required for an insert into a view · dd9a0770
      evgen@sunlight.local authored
      SELECT right instead of INSERT right was required for an insert into to a view.
      This wrong behaviour appeared after the fix for bug #20989. Its intention was
      to ask only SELECT right for all tables except the very first for a complex
      INSERT query. But that patch has done it in a wrong way and lead to asking 
      a wrong access right for an insert into a view.
      
      The setup_tables_and_check_access() function now accepts two want_access
      parameters. One will be used for the first table and the second for other
      tables.
      dd9a0770
  18. 19 Jul, 2006 1 commit
  19. 05 Jul, 2006 1 commit
    • guilhem@mysql.com's avatar
      Fix for BUG#20188 "REPLACE or ON DUPLICATE KEY UPDATE in · a43c4b02
      guilhem@mysql.com authored
      auto_increment breaks binlog":
      if slave's table had a higher auto_increment counter than master's (even
      though all rows of the two tables were identical), then in some cases,
      REPLACE and INSERT ON DUPLICATE KEY UPDATE failed to replicate
      statement-based (it inserted different values on slave from on master).
      write_record() contained a "thd->next_insert_id=0" to force an adjustment
      of thd->next_insert_id after the update or replacement. But it is this
      assigment introduced indeterminism of the statement on the slave, thus
      the bug. For ON DUPLICATE, we replace that assignment by a call to
      handler::adjust_next_insert_id_after_explicit_value() which is deterministic
      (does not depend on slave table's autoinc counter). For REPLACE, this
      assignment can simply be removed (as REPLACE can't insert a number larger
      than thd->next_insert_id).
      We also move a too early restore_auto_increment() down to when we really know
      that we can restore the value.
      a43c4b02
  20. 04 Jul, 2006 1 commit
    • gkodinov@mysql.com's avatar
      Bug #16110: insert permitted into view col w/o default value · b64089e6
      gkodinov@mysql.com authored
      When compiling INSERT statements the check whether columns are provided values
      depends on the flag whether a field is used in that query (Field::query_id).
      However the check for updatability of VIEW columns (check_view_insertability())
      was calling fix_fields() and thus setting the Field::query_id even for the 
      view fields that are not referenced in the current INSERT statement.
      So the correct check for columns without default values 
      ( check_that_all_fields_are_given_values() ) is assuming that all the VIEW
      columns were mentioned in the INSERT field list and was issuing no 
      warnings or errors.
      Fixed check_view_insertability() to turn off the flag whether or not to set
      Field::query_id (THREAD::set_query_id) before calling fix fields and restore
      it when it's done.
      b64089e6
  21. 01 Jul, 2006 1 commit
    • dlenev@mysql.com's avatar
      Fix for bug#18437 "Wrong values inserted with a before update trigger on · d4450e66
      dlenev@mysql.com authored
      NDB table".
      
      SQL-layer was not marking fields which were used in triggers as such. As
      result these fields were not always properly retrieved/stored by handler
      layer. So one might got wrong values or lost changes in triggers for NDB,
      Federated and possibly InnoDB tables.
      This fix solves the problem by marking fields used in triggers
      appropriately.
      
      Also this patch contains the following cleanup of ha_ndbcluster code:
      
      We no longer rely on reading LEX::sql_command value in handler in order
      to determine if we can enable optimization which allows us to handle REPLACE
      statement in more efficient way by doing replaces directly in write_row()
      method without reporting error to SQL-layer.
      Instead we rely on SQL-layer informing us whether this optimization
      applicable by calling handler::extra() method with
      HA_EXTRA_WRITE_CAN_REPLACE flag.
      As result we no longer apply this optimzation in cases when it should not
      be used (e.g. if we have on delete triggers on table) and use in some
      additional cases when it is applicable (e.g. for LOAD DATA REPLACE).
      
      Finally this patch includes fix for bug#20728 "REPLACE does not work
      correctly for NDB table with PK and unique index".
        
      This was yet another problem which was caused by improper field mark-up.
      During row replacement fields which weren't explicity used in REPLACE
      statement were not marked as fields to be saved (updated) so they have
      retained values from old row version. The fix is to mark all table
      fields as set for REPLACE statement. Note that in 5.1 we already solve
      this problem by notifying handler that it should save values from all
      fields only in case when real replacement happens.
      d4450e66
  22. 26 Jun, 2006 3 commits
    • konstantin@mysql.com's avatar
      A fix and a test case for · 117b76a5
      konstantin@mysql.com authored
       Bug#19022 "Memory bug when switching db during trigger execution"
       Bug#17199 "Problem when view calls function from another database."
       Bug#18444 "Fully qualified stored function names don't work correctly in
                  SELECT statements"
      
       Documentation note: this patch introduces a change in behaviour of prepared
       statements.
      
       This patch adds a few new invariants with regard to how THD::db should
       be used. These invariants should be preserved in future:
      
        - one should never refer to THD::db by pointer and always make a deep copy
          (strmake, strdup)
        - one should never compare two databases by pointer, but use strncmp or
          my_strncasecmp
        - TABLE_LIST object table->db should be always initialized in the parser or
          by creator of the object.
      
          For prepared statements it means that if the current database is changed
          after a statement is prepared, the database that was current at prepare
          remains active. This also means that you can not prepare a statement that
          implicitly refers to the current database if the latter is not set.
          This is not documented, and therefore needs documentation. This is NOT a
          change in behavior for almost all SQL statements except:
           - ALTER TABLE t1 RENAME t2 
           - OPTIMIZE TABLE t1
           - ANALYZE TABLE t1
           - TRUNCATE TABLE t1 --
           until this patch t1 or t2 could be evaluated at the first execution of
           prepared statement. 
      
           CURRENT_DATABASE() still works OK and is evaluated at every execution
           of prepared statement.
      
           Note, that in stored routines this is not an issue as the default
           database is the database of the stored procedure and "use" statement
           is prohibited in stored routines.
      
        This patch makes obsolete the use of check_db_used (it was never used in the
        old code too) and all other places that check for table->db and assign it
        from THD::db if it's NULL, except the parser.
      
       How this patch was created: THD::{db,db_length} were replaced with a
       LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
       manually checked and:
        - if the place uses thd->db by pointer, it was fixed to make a deep copy
        - if a place compared two db pointers, it was fixed to compare them by value
          (via strcmp/my_strcasecmp, whatever was approproate)
       Then this intermediate patch was used to write a smaller patch that does the
       same thing but without a rename.
      
       TODO in 5.1:
         - remove check_db_used
         - deploy THD::set_db in mysql_change_db
      
       See also comments to individual files.
      117b76a5
    • ingo@mysql.com's avatar
      Bug#16218 - Crash on insert delayed · 8728fbbc
      ingo@mysql.com authored
      Bug#17294 - INSERT DELAYED puting an \n before data
      Bug#16611 - INSERT DELAYED corrupts data
      Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
      Combined as Bug#16218.
      
      INSERT DELAYED crashed in 5.0 on a table with a varchar that 
      could be NULL and was created pre-5.0 (Bugs 16218 and 13707).
      INSERT DELAYED corrupted data in 5.0 on a table with varchar 
      fields that was created pre-5.0 (Bugs 17294 and 16611).
      
      In case of INSERT DELAYED the open table is copied from the
      delayed insert thread to be able to create a record for the 
      queue. When copying the fields, a method was used that did 
      convert old varchar to new varchar fields and did not set up 
      some pointers into the record buffer of the table.
      
      The field conversion was guilty for the misinterpretation of 
      the record contents by the delayed insert thread. The wrong
      pointer setup was guilty for the crashes.
      
      For Bug 13707 (Server crash with INSERT DELAYED on MyISAM table)
      I fixed the above mentioned method to set up one of the pointers.
      For Bug 16218 I set up the other pointers too.
      
      But when looking at the corruptions I got aware that converting
      the field type was totally wrong for INSERT DELAYED. The copied
      table is used to create a record that is to be sent to the
      delayed insert thread. Of course it can interpret the record
      correctly only if all field types are the same in both table
      objects.
      
      So I revoked the fix for Bug 13707 and changed the new_field() 
      method so that it can suppress conversions.
      
      No test case as this is a migration problem. One needs to
      create a table with 4.x and use it with 5.x. I added two
      test scripts to the bug report.
      8728fbbc
    • ingo@mysql.com's avatar
      Bug#16986 - Deadlock condition with MyISAM tables · d27a15a8
      ingo@mysql.com authored
      Addendum fixes after changing the condition variable
      for the global read lock.
      
      The stress test suite revealed some deadlocks. Some were
      related to the new condition variable (COND_global_read_lock)
      and some were general problems with the global read lock.
      
      It is now necessary to signal COND_global_read_lock whenever 
      COND_refresh is signalled.
      
      We need to wait for the release of a global read lock if one 
      is set before every operation that requires a write lock.
      But we must not wait if we have locked tables by LOCK TABLES.
      After setting a global read lock a thread waits until all
      write locks are released.
      d27a15a8
  23. 16 Jun, 2006 1 commit
    • dlenev@mysql.com's avatar
      Fix for bug#13479 "REPLACE activates UPDATE trigger, not the DELETE and · 59d20e26
      dlenev@mysql.com authored
      INSERT triggers".
      
      In cases when REPLACE was internally executed via update and table had
      on update (on delete) triggers defined we exposed the fact that such
      optimization used by callng on update (not calling on delete) triggers.
      Such behavior contradicts our documentation which describes REPLACE as
      INSERT with optional DELETE.
      
      This fix just disables this optimization for tables with on delete triggers.
      The optimization is still applied for tables which have on update but have
      no on delete triggers, we just don't invoke on update triggers in this case
      and thus don't expose information about optimization to user.
      
      Also added test coverage for values returned by ROW_COUNT() function (and
      thus for values returned by mysql_affected_rows()) for various forms of
      INSERT.
      59d20e26
  24. 13 Jun, 2006 1 commit
    • gkodinov@mysql.com's avatar
      Bug #20195: INSERT DELAYED with auto_increment is assigned wrong values · 8d94b8ca
      gkodinov@mysql.com authored
      The INSERT DELAYED should not maintain its own private auto-increment
      counter, because this is assuming that other threads cannot insert
      into the table while the INSERT DELAYED thread is inserting, which is
      a wrong assumption.
      
      So the start of processing of a batch of INSERT rows in the 
      INSERT DELAYED thread must be treated as a start of a new statement
      and cached next_insert_id must be cleared.
      8d94b8ca
  25. 26 May, 2006 1 commit
    • gkodinov@mysql.com's avatar
      BUG#18681: View privileges are broken · a21a2b5b
      gkodinov@mysql.com authored
      The check for view security was lacking several points :
      1. Check with the right set of permissions : for each table ref that
      participates in a view there were the right credentials to use in it's
      security_ctx member, but these weren't used for checking the credentials.
      This makes hard enforcing the SQL SECURITY DEFINER|INVOKER property
      consistently.
      2. Because of the above the security checking for views was just ruled out
      in explicit ways in several places.
      3. The security was checked only for the columns of the tables that are
      brought into the query from a view. So if there is no column reference
      outside of the view definition it was not detecting the lack of access to
      the tables in the view in SQL SECURITY INVOKER mode.
      
      The fix below tries to fix the above 3 points.
      a21a2b5b
  26. 24 May, 2006 1 commit
    • monty@mysql.com's avatar
      Remove dflt_field from field structure as this was only needed when createing... · 97b941d9
      monty@mysql.com authored
      Remove dflt_field from field structure as this was only needed when createing temporary table and I found another soultion that doesn't increase the size of the field structure for all table instances. (Better fix for bug #19089)
      Fixed compiler warnings
      Fixed valgrind warning in Item_date_add_intervall::eq. (Recoding of bugfix #19490)
      97b941d9
  27. 09 May, 2006 1 commit
    • dlenev@mysql.com's avatar
      Fix for bugs#12472/#15137 'CREATE TABLE ... SELECT ... which explicitly · 589daad1
      dlenev@mysql.com authored
      or implicitly uses stored function gives "Table not locked" error'
      
      CREATE TABLE ... SELECT ... statement which was explicitly or implicitly
      (through view) using stored function gave "Table not locked" error.
      
      The actual bug resides in the current locking scheme of CREATE TABLE SELECT
      code, which first opens and locks tables of the SELECT statement itself,
      and then, having SELECT tables locked, creates the .FRM, opens the .FRM and
      acquires lock on it. This scheme opens a possibility for a deadlock, which
      was present and ignored since version 3.23 or earlier. This scheme also
      conflicts with the invariant of the prelocking algorithm -- no table can
      be open and locked while there are tables locked in prelocked mode.
      
      The patch makes an exception for this invariant when doing CREATE TABLE ...
      SELECT, thus extending the possibility of a deadlock to the prelocked mode.
      We can't supply a better fix in 5.0.
      589daad1
  28. 05 Apr, 2006 1 commit
    • ingo@mysql.com's avatar
      BUG#5390 - problems with merge tables · c864ac15
      ingo@mysql.com authored
      Additional fix for INSERT DELAYED with subselect.
      Originally detected in 5.1, but 5.0 could also be affected.
      The user thread creates a dummy table object,
      which is not included in the lock. The 'real' table is
      opened and locked by the 'delayed' system thread.
      The dummy object is now marked as not locked and this is
      tested in mysql_lock_have_duplicate().
      c864ac15
  29. 04 Apr, 2006 1 commit
  30. 29 Mar, 2006 1 commit
    • dlenev@mysql.com's avatar
      Proposed fix for bug #17764 "Trigger crashes MyISAM table" · 17785d16
      dlenev@mysql.com authored
      A table with an on insert trigger was reported as crashed when the insert
      was processed with bulk insert mode on (handler::start_bulk_insert).
      The trigger was also selecting from the same table, and that caused
      the "crash".
      The same problem was present when an insert statement, which was processed
      in bulk mode, also used a stored function that was reading the same table.
      
      This fix disables bulk inserts if a statement uses functions or invokes
      triggers. Implementing more granular checks will require much more code and
      therefore can hardly be done in 5.0
      17785d16
  31. 15 Mar, 2006 1 commit
  32. 05 Jan, 2006 1 commit
    • monty@mysql.com's avatar
      Review fixes of new pushed code · 6e22e29d
      monty@mysql.com authored
      - Fixed tests
      - Optimized new code
      - Fixed some unlikely core dumps
      - Better bug fixes for:
        - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash
        - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
      6e22e29d
  33. 03 Jan, 2006 1 commit
  34. 20 Dec, 2005 1 commit
    • ingo@mysql.com's avatar
      BUG#5390 - problems with merge tables · b0e84cb9
      ingo@mysql.com authored
      Problem #1: INSERT...SELECT, Version for 5.0.
      Extended the unique table check by a check of lock data.
      Merge sub-tables cannot be detected by doing name checks only.
      b0e84cb9
  35. 08 Dec, 2005 1 commit
  36. 28 Nov, 2005 1 commit
  37. 23 Nov, 2005 1 commit
  38. 11 Oct, 2005 1 commit
    • monty@mysql.com's avatar
      Reviewing new pushed code · f5fdf3e8
      monty@mysql.com authored
      - CHAR() now returns binary string as default
      - CHAR(X*65536+Y*256+Z) is now equal to CHAR(X,Y,Z) independent of the character set for CHAR()
      - Test for both ETIMEDOUT and ETIME from pthread_cond_timedwait()
        (Some old systems returns ETIME and it's safer to test for both values
         than to try to write a wrapper for each old system)
      - Fixed new introduced bug in NOT BETWEEN X and X
      - Ensure we call commit_by_xid or rollback_by_xid for all engines, even if one engine has failed
      - Use octet2hex() for all conversion of string to hex
      - Simplify and optimize code
      f5fdf3e8