An error occurred fetching the project authors.
  1. 07 Dec, 2006 1 commit
  2. 06 Dec, 2006 1 commit
  3. 30 Nov, 2006 1 commit
  4. 28 Nov, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      BUG#11927: Warnings shown for CAST( chr as signed) but not (chr + 0) · 42cd9567
      gkodinov/kgeorge@macbook.gmz authored
       When implicitly converting string fields to numbers the 
       string-to-number conversion error was not sent to the client.
       Added code to send the conversion error as warning.
       
       We also need to prevent generation of warnings from the places
       where val_xxx() methods are called for the sole purpose of updating
       the Item::null_value flag.
       To achieve that a special function is added (and called) : 
       update_null_value(). This function will set the no_errors flag and
       will call val_xxx(). The warning generation in Field_string::val_xxx()
       will use the flag when generating the conversion warnings. 
      42cd9567
  5. 09 Nov, 2006 1 commit
  6. 07 Nov, 2006 1 commit
  7. 06 Nov, 2006 1 commit
  8. 30 Oct, 2006 1 commit
  9. 25 Oct, 2006 1 commit
  10. 04 Oct, 2006 1 commit
    • kaa@polly.local's avatar
      Fixes a number of problems with time/datetime <-> string conversion functions: · 609a3cd2
      kaa@polly.local authored
      - bug #11655 "Wrong time is returning from nested selects - maximum time exists
      - input and output TIME values were not validated properly in several conversion functions
      - bug #20927 "sec_to_time treats big unsigned as signed"
      - integer overflows were not checked in several functions. As a result, input values like 2^32 or 3600*2^32 were treated as 0
      - BIGINT UNSIGNED values were treated as SIGNED in several functions
      - in cases where both input string truncation and out-of-range TIME value occur, only 'truncated incorrect time value' warning was produced
      609a3cd2
  11. 29 Sep, 2006 1 commit
  12. 28 Sep, 2006 1 commit
  13. 27 Sep, 2006 1 commit
  14. 29 Aug, 2006 1 commit
    • kostja@bodhi.local's avatar
      A fix for Bug#14897 "ResultSet.getString("table.column") sometimes · 3bf609b7
      kostja@bodhi.local authored
      doesn't find the column"
      
      When a user was using 4.1 tables with VARCHAR column and 5.0 server
      and a query that used a temporary table to resolve itself, the
      table metadata for the varchar column sent to client was incorrect:
      MYSQL_FIELD::table member was empty.
      
      The bug was caused by implicit "upgrade" from old VARCHAR to new
      VARCHAR hard-coded in Field::new_field, which did not preserve
      the information about the original table. Thus, the field metadata
      of the "upgraded" field pointed to an auxiliary temporary table
      created for query execution.
      
      The fix is to copy the pointer to the original table to the new field.
      3bf609b7
  15. 15 Aug, 2006 1 commit
  16. 14 Aug, 2006 1 commit
  17. 21 Jul, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#12185: Data type aggregation may produce wrong result · c875b8eb
      evgen@moonbone.local authored
      The Item::tmp_table_field_from_field_type() function creates Field_datetime
      object instead of Field_timestamp object for timestamp field thus always
      changing data type is a tmp table is used.
      
      The Field_blob object constructor which is used in the 
      Item::tmp_table_field_from_field_type() is always setting packlength field of
      newly created blob to 4. This leads to changing fields data type for example
      from the blob to the longblob if a temporary table is used.
      
      The Item::make_string_field() function always converts Field_string objects 
      to Field_varstring objects. This leads to changing data type from the 
      char/binary to varchar/varbinary.
      
      Added appropriate Field_timestamp object constructor for using in the 
      Item::tmp_table_field_from_field_type() function.
      
      Added Field_blob object constructor which sets pack length according to
      max_length argument.
      
      The Item::tmp_table_field_from_field_type() function now creates
      Field_timestamp object for a timestamp field.
      
      The Item_type_holder::display_length() now returns correct NULL length NULL
      length. 
      
      The Item::make_string_field() function now doesn't change Field_string to
      Field_varstring in the case of Item_type_holder. 
      
      The Item::tmp_table_field_from_field_type() function now uses the Field_blob
      constructor which sets packlength according to max_length.
      c875b8eb
  18. 20 Jul, 2006 1 commit
  19. 19 Jul, 2006 1 commit
  20. 18 Jul, 2006 1 commit
    • jimw@rama.(none)'s avatar
      Bug #19498: Inconsistent support for DEFAULT in TEXT columns · d18eacc7
      jimw@rama.(none) authored
        When a default of '' was specified for TEXT/BLOB columns, the specification
        was silently ignored. This is presumably to be nice to applications (or
        people) who generate their column definitions in a not-very-clever fashion.
      
        For clarity, doing this now results in a warning, or an error in strict
        mode.
      d18eacc7
  21. 12 Jul, 2006 1 commit
  22. 26 Jun, 2006 1 commit
    • 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
  23. 21 Jun, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug #14896. · 8d4a910a
      evgen@moonbone.local authored
      This bug in Field_string::cmp resulted in a wrong comparison 
      with keys in partial indexes over multi-byte character fields.
      Given field a is declared as a varchar(16) collate utf8_unicode_ci
      INDEX(a(4)) gives us an example of such an index.
        
      Wrong key comparisons could lead to wrong result sets if 
      the selected query execution plan used a range scan by 
      a partial index over a utf8 character field.
      This also caused wrong results in many other cases.
      8d4a910a
  24. 20 Jun, 2006 1 commit
    • evgen@moonbone.local's avatar
      field.cc, field.h: · 8c0aa356
      evgen@moonbone.local authored
        Additional fix for #16377 for bigendian platforms
      sql_select.cc, select.result, select.test:
        After merge fix
      8c0aa356
  25. 14 Jun, 2006 2 commits
    • evgen@moonbone.local's avatar
      Many files: · a2261d57
      evgen@moonbone.local authored
        After merge fix
      a2261d57
    • igor@rurik.mysql.com's avatar
      Fixed bug #14896. · 355753ba
      igor@rurik.mysql.com authored
      This bug in Field_string::cmp resulted in a wrong comparison 
      with keys in partial indexes over multi-byte character fields.
      Given field a is declared as 
        a varchar(16) collate utf8_unicode_ci
      INDEX(a(4)) gives us an example of such an index.
      
      Wrong key comparisons could lead to wrong result sets if 
      the selected query execution plan used a range scan by 
      a partial index over a utf8 character field.
      This also caused wrong results in many other cases.
      355753ba
  26. 13 Jun, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#16377: result of DATE/TIME functions were compared as strings which · 67de8c46
      evgen@moonbone.local authored
      can lead to a wrong result.
      
      All date/time functions has the STRING result type thus their results are
      compared as strings. The string date representation allows a user to skip 
      some of leading zeros. This can lead to wrong comparison result if a date/time 
      function result is compared to such a string constant.
      
      The idea behind this bug fix is to compare results of date/time functions
      and data/time constants as ints, because that date/time representation is 
      more exact. To achieve this the agg_cmp_type() is changed to take in the
      account that a date/time field or an date/time item should be compared 
      as ints.
      
      This bug fix is partially back ported from 5.0.
      
      The agg_cmp_type() function now accepts THD as one of parameters. 
      In addition, it now checks if a date/time field/function is present in the
      list. If so, it tries to coerce all constants to INT to make date/time
      comparison return correct result. The field for the constant coercion is
      taken from the Item_field or constructed from the Item_func. In latter case
      the constructed field will be freed after conversion of all constant items.
      Otherwise the result is same as before - aggregated with help of the
      item_cmp_type() function.
      
      From the Item_func_between::fix_length_and_dec() function removed the part
      which was converting date/time constants to int if possible. Now this is 
      done by the agg_cmp_type() function.
      
      The new function result_as_longlong() is added to the Item class. 
      It indicates that the item is a date/time item and result of it can be
      compared as int. Such items are date/time fields/functions.
      
      Correct val_int() methods are implemented for classes Item_date_typecast, 
      Item_func_makedate, Item_time_typecast, Item_datetime_typecast. All these
      classes are derived from Item_str_func and Item_str_func::val_int() converts
      its string value to int without regard to the date/time type of these items.
      
      Arg_comparator::set_compare_func() and Arg_comparator::set_cmp_func()
      functions are changed to substitute result type of an item with the INT_RESULT
      if the item is a date/time item and another item is a constant. This is done
      to get a correct result of comparisons like date_time_function() = string_constant.
      67de8c46
  27. 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
  28. 22 May, 2006 1 commit
  29. 21 May, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #19089. · 12e53358
      igor@rurik.mysql.com authored
      When a CREATE TABLE command created a table from a materialized
      view id does not inherit default values from the underlying table.
      Moreover the temporary table used for the view materialization
      does not inherit those default values.
      In the case when the underlying table contained ENUM fields it caused
      misleading error messages. In other cases the created table contained
      wrong default values.
      The code was modified to ensure inheritance of default values for
      materialized views.
      12e53358
  30. 17 May, 2006 1 commit
  31. 05 Apr, 2006 1 commit
    • jimw@mysql.com's avatar
      Bug #13601: Wrong int type for bit · 1a59580d
      jimw@mysql.com authored
        The wrong value was being reported as the field_length for BIT
        fields, resulting in confusion for at least Connector/J. The
        field_length is now always the number of bits in the field, as
        it should be.
      1a59580d
  32. 29 Mar, 2006 1 commit
  33. 25 Feb, 2006 1 commit
  34. 23 Feb, 2006 1 commit
  35. 21 Feb, 2006 1 commit
  36. 20 Jan, 2006 1 commit
  37. 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
  38. 03 Jan, 2006 1 commit
  39. 28 Dec, 2005 1 commit