An error occurred fetching the project authors.
  1. 06 May, 2008 1 commit
    • unknown's avatar
      Partial rollback of fix for bug #30059: End-space truncation is inconsistent · 5a1b7ddb
      unknown authored
      or incorrect.
      
      For better conformance with standard, truncation procedure of CHAR columns
      has been changed to ignore truncation of trailing whitespace characters
      (note has been removed).
      
      Finally, for columns with non-binary charsets:
      
      1. CHAR(N) columns silently ignore trailing whitespace truncation;
      2. VARCHAR and TEXT columns issue Note about truncation.
      
      BLOBs and other columns with BINARY charset are unaffected.
      
      
      
      
      
      mysql-test/r/bdb.result:
        Rollback of bug #30059 fix.
      mysql-test/r/heap.result:
        Rollback of bug #30059 fix.
      mysql-test/r/innodb.result:
        Rollback of bug #30059 fix.
      mysql-test/r/myisam.result:
        Rollback of bug #30059 fix.
      mysql-test/r/strict.result:
        Rollback of bug #30059 fix.
      mysql-test/r/type_binary.result:
        Rollback of bug #30059 fix.
      mysql-test/r/warnings.result:
        Updated test case for bug #30059.
      sql/field.cc:
        Post-commit fix for bug #30059.
        
        The Field_longstr::report_if_important_data method
        has been changed to notify about trailing spaces only if
        the new count_spaces parameter is TRUE.
        
        The Field_string::store method has been changed to
        ignore trailing whitespace truncation (CHAR column
        type).
      sql/field.h:
        Post-commit fix for bug #30059.
        
        The Field_longstr::report_if_important_data method declaration
        has been changed to accept extra parameter: bool count_spaces.
      5a1b7ddb
  2. 10 Apr, 2008 1 commit
    • unknown's avatar
      Fix mismerge. · 57784eae
      unknown authored
      sql/field.cc:
        Fix indentation of new line.
      57784eae
  3. 09 Apr, 2008 1 commit
    • unknown's avatar
      Follow-up to B-g#15776, test failures on 64-bit linux. · 2bc7179d
      unknown authored
      Make maximum blob size to be 2**32-1, regardless of word size.
      
      Fix failure of timestamp with size of 2**31-1.  The method of
      rounding up to the nearest even number would overflow.
      
      
      mysql-test/r/type_blob.result:
        2**32-1 is not a special case for timestamp.
        
        Test 2**32-1 and 2**64 as the reliable test points for both 32-
        and 64-bit machines.  I'd like to test 2**32, but that would make 
        tests that vary between architectures.
        
        I'd like to generalize the tests by pulling the max blob size from
        the server, and then "eval"ing N-1, N, and N+1 instead of all these
        literal numbers, but I have not found a way to get UINT_MAX.
      mysql-test/t/type_blob.test:
        2**32-1 is not a special case for timestamp.
        
        Test 2**32-1 and 2**64 as the reliable test points for both 32-
        and 64-bit machines.  I'd like to test 2**32, but that would make 
        tests that vary between architectures.
        
        I'd like to generalize the tests by pulling the max blob size from
        the server, and then "eval"ing N-1, N, and N+1 instead of all these
        literal numbers, but I have not found a way to get UINT_MAX.
      sql/field.cc:
        Fix a bug where the round-to-even code for TIMESTAMP fields
        failed where the size would overflow the size to zero and then
        fail.
        
        Also, since we silently truncate the size of TIMESTAMP fields, set
        the maximum size we report is allowable to be the largest parsable
        number.
      sql/unireg.h:
        Make BLOB size the maximum that the packed value in 
        field_blob::get_length() allows.
      2bc7179d
  4. 08 Feb, 2008 1 commit
    • unknown's avatar
      Fixed bug#15409: Columns with 64-element SET may not be updated with integers. · 213b4dcd
      unknown authored
      SET column storing procedure has been modified to be 64bit-clean.
      
      
      mysql-test/r/type_set.result:
        Added test case for bug#15409.
      mysql-test/t/type_set.test:
        Added test case for bug#15409.
      sql/field.cc:
        Fixed bug#15409.
        The Field_set::store(longlong nr,...) method incompletely
        calculates a bit mask for the comparison with a given number:
        if that number is greater than 0x7F00 0000 0000 0000 (LONGLONG_MAX),
        it uses zero bit mask instead of 0xFFFF FFFF FFFF FFFF (ULONGLONG_MAX).
        
        Incomplete expression has been replaced with a set_bits macro call.
      213b4dcd
  5. 06 Feb, 2008 1 commit
    • unknown's avatar
      Fixed bug#30059. · 3891d436
      unknown authored
      Server handles truncation for assignment of too-long values
      into CHAR/VARCHAR/TEXT columns in a different ways when the
      truncated characters are spaces:
      1. CHAR(N) columns silently ignore end-space truncation;
      2. TEXT columns post a truncation warning/error in the
         non-strict/strict mode.
      3. VARCHAR columns always post a truncation note in
         any mode.
      
      Space truncation processing has been synchronised over
      CHAR/VARCHAR/TEXT columns: current behavior of VARCHAR
      columns has been propagated as standard.
      
      Binary-encoded string/BLOB columns are not affected.
      
      
      mysql-test/r/heap.result:
        Updated test case for bug#30059.
      mysql-test/r/innodb.result:
        Updated test case for bug#30059.
      mysql-test/r/myisam.result:
        Updated test case for bug#30059.
      mysql-test/r/strict.result:
        Updated test case for bug#30059.
      mysql-test/r/type_binary.result:
        Updated test case for bug#30059.
      mysql-test/r/warnings.result:
        Added test case for bug#30059.
      mysql-test/t/warnings.test:
        Added test case for bug#30059.
      sql/field.cc:
        Fixed bug#30059.
        The report_data_too_long function was replaced with the
        Field_longstr::report_if_important_data method.
        
        The Field_string::store and the Field_blob::store
        methods was synchronized with the Field_varstring::store
        method.
        Changes:
        1. to CHAR(N): posting of space truncation note has been added
           in both (strict and non-strict) modes;
        2. to BLOBs: a check for space truncation has been added,
           a warning in the non-strict mode and an error message in
           the strict mode have been replaced with a truncation note.
        
        Similar parts of Field_string::store, Field_blob::store and
        Field_varstring::store have been moved to the
        Field_longstr::report_if_important_data method.
      sql/field.h:
        Fixed bug#30059.
        The Field_longstr::report_if_important_data method has been declared.
      3891d436
  6. 13 Dec, 2007 1 commit
    • unknown's avatar
      BUG#32198: Comparison of DATE with DATETIME still not using indexes correctly · c6675cd1
      unknown authored
      - Make conditions like "date_col $CMP$ 'datetime-const'" range-sargable
      
      
      mysql-test/r/range.result:
        BUG#32198: Comparison of DATE with DATETIME still not using indexes correctly
        - Testcase
      mysql-test/t/range.test:
        BUG#32198: Comparison of DATE with DATETIME still not using indexes correctly
        - Testcase
      sql/field.cc:
        BUG#32198: Comparison of DATE with DATETIME still not using indexes correctly
        - Added comments
      c6675cd1
  7. 11 Dec, 2007 2 commits
    • unknown's avatar
      Bug#32848: Data type conversion bug in union subselects in MySQL 5.0.38 · 94f75ffc
      unknown authored
      There were two problems when inferring the correct field types resulting from
      UNION queries.
      - If the type is NULL for all corresponding fields in the UNION, the resulting 
        type would be NULL, while the type is BINARY(0) if there is just a single 
        SELECT NULL.
      - If one SELECT in the UNION uses a subselect, a temporary table is created
        to represent the subselect, and the result type defaults to a STRING type,
        hiding the fact that the type was unknown(just a NULL value).
      Fixed by remembering whenever a field was created from a NULL value and pass
      type NULL to the type coercion if that is the case, and creating a string field
      as result of UNION only if the type would otherwise be NULL.
      
      
      mysql-test/r/union.result:
        Bug#32848: Test result
      mysql-test/t/union.test:
        Bug#32848: Test case
      sql/field.cc:
        Bug#32848: Initialization of new field
      sql/field.h:
        Bug#32848: New member to record when a field was created from a NULL value.
      sql/item.cc:
        Bug#32848: 
        A field created from a NULL value will submit NULL as type to the 
        type coercion procedure.
        If Item_type_holder has not inferred the correct type after processing all
        SELECTs in a UNION, a string field is created.
      sql/sql_select.cc:
        Bug#32848: Recording when a field is created from a NULL value.
      94f75ffc
    • unknown's avatar
      Bug#31990: MINUTE() and SECOND() return bogus results when used on a DATE · 08b256f9
      unknown authored
      HOUR(), MINUTE(), ... returned spurious results when used on a DATE-cast.
      This happened because DATE-cast object did not overload get_time() method
      in superclass Item. The default method was inappropriate here and
      misinterpreted the data.
      
      Patch adds missing method; get_time() on DATE-casts now returns SQL-NULL
      on NULL input, 0 otherwise. This coincides with the way DATE-columns
      behave.
      
      Also fixes similar bug in Date-Field now.
      
      
      mysql-test/r/cast.result:
        Show that HOUR(), MINUTE(), ... return sensible values when used
        on DATE-cast objects, namely NULL for NULL-dates and 0 otherwise.
        Show that this coincides with how DATE-columns behave.
      mysql-test/r/type_date.result:
        Show that HOUR(), MINUTE(), ... return sensible values when used
        on DATE-fields.
      mysql-test/t/cast.test:
        Show that HOUR(), MINUTE(), ... return sensible values when used
        on DATE-cast objects, namely NULL for NULL-dates and 0 otherwise.
        Show that this coincides with how DATE-columns behave.
      mysql-test/t/type_date.test:
        Show that HOUR(), MINUTE(), ... return sensible values when used
        on DATE-fields.
      sql/field.cc:
        Add get_time() method to DATE-field object to overload
        the method in Field superclass that would return spurious
        results. Return zero-result.
      sql/field.h:
        Add get_time() declaration to date-field class
      sql/item_timefunc.cc:
        Add get_time() method to DATE-cast object to overload
        the method in Item superclass that would return spurious
        results. Return zero-result; flag NULL if input was NULL.
      sql/item_timefunc.h:
        Add get_time() declaration to DATE-cast object.
      08b256f9
  8. 02 Dec, 2007 1 commit
    • unknown's avatar
      Windows-specific fixes in floating point tests. · 5fd87aba
      unknown authored
      mysql-test/t/insert.test:
        Windows implements a different rounding rules in printf("%g"), thus we still need to do replace_result
      mysql-test/t/variables.test:
        We need to do replace_result because variables are printed by another procedure.
      sql/field.cc:
        Fixed the code to limit the precision to DBL_DIG.
      5fd87aba
  9. 01 Dec, 2007 3 commits
    • unknown's avatar
      Fixed the floating point number tests on Windows. · 1f22720c
      unknown authored
      mysql-test/r/insert.result:
        Fixed the test cases.
      mysql-test/t/cast.test:
        We need to do replace_result because warnings are printed by another procedure.
      mysql-test/t/insert.test:
        Windows implements a different rounding rules in printf("%g"), thus we still need to do replace_result.
      sql/field.cc:
        Limit the precision to avoid garbage past the significant digits.
      1f22720c
    • unknown's avatar
      Fixed the build failure on Windows. It does not have trunc() defined in... · d8d07eff
      unknown authored
      Fixed the build failure on Windows. It does not have trunc() defined in math.h, so we should not use it code.
      
      
      
      d8d07eff
    • unknown's avatar
      Fix for bug #26788 "mysqld (debug) aborts when inserting specific · 1615f838
      unknown authored
      numbers into char fields" and bug #12860 "Difference in zero padding of
      exponent between Unix and Windows"
      
      Rewrote the code that determines what 'precision' argument should be
      passed to sprintf() to fit the string representation of the input number
      into the field.
      We get finer control over conversion by pre-calculating the exponent, so
      we are able to determine which conversion format, 'e' or 'f', will be
      used by sprintf().
      We also remove the leading zero from the exponent on Windows to make it
      compatible with the sprintf() output on other platforms.
      
      
      mysql-test/r/insert.result:
        Added test cases for bug #26788 and bug #31152.
      mysql-test/t/cast.test:
        Removed --replace_result, since the result is now correct on Windows.
      mysql-test/t/insert.test:
        Added test cases for bug #26788 and bug #31152.
      mysql-test/t/type_float.test:
        Removed --replace_result, since the result is now correct on Windows.
      mysql-test/t/variables.test:
        Removed --replace_result, since the result is now correct on Windows.
      sql/field.cc:
        Rewrote the code that determines what 'precision' argument should be
        passed to sprintf() to fit the string representation of the input number
        into the field.
        We get finer control over conversion by pre-calculating the exponent, so
        we are able to determine which conversion format, 'e' or 'f', will be
        used by sprintf().
      1615f838
  10. 13 Nov, 2007 1 commit
    • unknown's avatar
      Bug #31158 Spatial, Union, LONGBLOB vs BLOB bug (crops data) · eb347921
      unknown authored
      max_length parameter for BLOB-returning functions must be big enough
      for any possible content. Otherwise the field created for a table
      will be too small.
      
      
      mysql-test/r/gis.result:
        Bug #31158  Spatial, Union, LONGBLOB vs BLOB bug (crops data)
        
        test result
      mysql-test/t/gis.test:
        Bug #31158  Spatial, Union, LONGBLOB vs BLOB bug (crops data)
        
        test case
      sql/field.cc:
        Bug #31158  Spatial, Union, LONGBLOB vs BLOB bug (crops data)
        
        max_field_size used instead of numeric value
      sql/field.h:
        Bug #31158  Spatial, Union, LONGBLOB vs BLOB bug (crops data)
        
        max_field_size constant defined
      sql/item_geofunc.cc:
        Bug #31158  Spatial, Union, LONGBLOB vs BLOB bug (crops data)
        
        max_length parameter fixed
      eb347921
  11. 19 Oct, 2007 1 commit
  12. 18 Oct, 2007 1 commit
    • unknown's avatar
      Bug #31221: Optimizer incorrectly identifies impossible WHERE clause · 787a4b48
      unknown authored
       No warning was generated when a TIMESTAMP with a non-zero time part
       was converted to a DATE value. This caused index lookup to assume
       that this is a valid conversion and was returning rows that match 
       a comparison between a TIMESTAMP value and a DATE keypart.
       Fixed by generating a warning on such a truncation.
      
      
      mysql-test/r/derived.result:
        Bug #31221: fixed an existing not-precise test case
      mysql-test/r/ps_2myisam.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/ps_3innodb.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/ps_4heap.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/ps_5merge.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/ps_6bdb.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/ps_7ndb.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/type_date.result:
        Bug #31221: Warnings cased by existing tests
      mysql-test/r/type_datetime.result:
        Bug #31221: test case
      mysql-test/t/derived.test:
        Bug #31221: fixed an existing not-precise test case
      mysql-test/t/type_date.test:
        Bug #31221: test case
      sql/field.cc:
        Bug #31221: 
         - Upgraded fix for bug 29729
         - issue a warning only if the hh:mm:ss.msec is not zero consistently 
           for all the Field_newdate::store function
      sql/item_timefunc.cc:
        Bug #31221: don't ignore the errors when storing data
      787a4b48
  13. 10 Oct, 2007 1 commit
    • unknown's avatar
      Bug #30825: Problems when putting a non-spatial index on a GIS column · aec287fd
      unknown authored
       Fixed the usage of spatial data (and Point in specific) with 
       non-spatial indexes.
       Several problems :
         - The length of the Point class was not updated to include the 
           spatial reference system identifier. Fixed by increasing with 4 
           bytes.
         - The storage length of the spatial columns was not accounting for
           the length that is prepended to it. Fixed by treating the 
           spatial data columns as blobs (and thus increasing the storage
           length)
         - When creating the key image for comparison in index read wrong
           key image was created (the one needed for and r-tree search,
           not the one for b-tree/other search). Fixed by treating the
           spatial data columns as blobs (and creating the correct kind of
           image based on the index type). 
      
      
      mysql-test/r/bdb_gis.result:
        Bug #30825: bdb tests
      mysql-test/r/gis-rtree.result:
        Bug #30825: key length changed
      mysql-test/r/gis.result:
        Bug #30825: MyISAM tests
      mysql-test/r/innodb_gis.result:
        Bug #30825: InnoDB tests
      mysql-test/t/bdb_gis.test:
        Bug #30825: bdb tests
      mysql-test/t/gis.test:
        Bug #30825: MyISAM tests
      mysql-test/t/innodb_gis.test:
        Bug #30825: InnoDB tests
      sql/field.cc:
        Bug #30825: Removed Field_geom::get_key_image as Field_blog::get_key_image 
          takes type parameter into consideration and is a superset of 
          Field_geom::get_key_image()
      sql/field.h:
        Bug #30825: Removed Field_geom::get_key_image as Field_blog::get_key_image 
          takes type parameter into consideration and is a superset of 
          Field_geom::get_key_image()
      sql/sql_select.h:
        Bug #30825: Geometry data are a blob derivate
      sql/sql_table.cc:
        Bug #30825: Increased key length to accomodate for
          spatial reference system identifier (srid)
      sql/sql_yacc.yy:
        Bug #30825: Increased key length to accomodate for
          spatial reference system identifier (srid)
      sql/table.cc:
        Bug #30825: It stores a length for spatial data
         as well, so increase the storage length (as it's
         done for blobs).
      mysql-test/include/gis_keys.inc:
        Bug #30825: Test file for spatial data and non-spatial indexes
      aec287fd
  14. 04 Oct, 2007 1 commit
    • unknown's avatar
      Backport of the 5.0 patch to 4.1 · 4d0ef0cc
      unknown authored
      Bug#28878: InnoDB tables with UTF8 character set and indexes cause  wrong result for DML
      When making key reference buffers over CHAR fields whitespace (0x20) must be used to fill in the remaining space in the field's buffer. This is what Field_string::store() does. Fixed Field_string::get_key_image() to do the same.
      
      
      mysql-test/r/innodb_mysql.result:
        Bug#28878: test case
      mysql-test/t/innodb_mysql.test:
        Bug#28878: test case
      sql/field.cc:
        Bug#28878: Fill with space instead of binary zeros.
      4d0ef0cc
  15. 28 Sep, 2007 1 commit
    • unknown's avatar
      Bug#27990: Wrong info in MYSQL_FIELD struct members when a tmp table was used. · 6a8bd84a
      unknown authored
      The change_to_use_tmp_fields function leaves the orig_table member of an
      expression's tmp table field filled for the new Item_field being created.
      Later orig_table is used by the Field::make_field function to provide some
      info about original table and field name to a user. This is ok for a field
      but for an expression it should be empty.
      
      The change_to_use_tmp_fields function now resets orig_table member of
      an expression's tmp table field to prevent providing a wrong info to a user.
      The Field::make_field function now resets the table_name and the org_col_name
      variables when the orig_table is set to 0.
      
      
      sql/field.cc:
        Bug#27990: Wrong info in MYSQL_FIELD struct members when a tmp table was used.
        The Field::make_field function now resets the table_name and the org_col_name
        variables when the orig_table is set to 0.
      sql/sql_select.cc:
        Bug#27990: Wrong info in MYSQL_FIELD struct members when a tmp table was used.
        The change_to_use_tmp_fields function now resets orig_table member of
        an expression's tmp table field to prevent providing a wrong info to a user.
      tests/mysql_client_test.c:
        The test case for the bug#21635 is altered to test behavior on both const and
        non-const tables.
      6a8bd84a
  16. 31 Aug, 2007 1 commit
    • unknown's avatar
      Bug#15776: 32-bit signed int used for length of blob · 13fea36d
      unknown authored
      Based on contributed patch from Martin Friebe, CLA from 2007-02-24.
      
      The parser lacked support for field sizes after signed long,
      when it should extend to 2**32-1.
      
      Now, we correct that limitation, and also make the error handling
      consistent for casts.
      
      
      mysql-test/r/type_blob.result:
        Verify that blobs may be created with the size that is already
        documented.
        
        Additionally, test the limits of several other types.
      mysql-test/t/type_blob.test:
        Verify that blobs may be created with the size that is already
        documented.
        
        Additionally, test the limits of several other types.
      sql/field.cc:
        atoi() insufficient to gauge the length of some fields.  Change
        it to strtoul().
      sql/item_create.cc:
        atoi() insufficient to gauge the length of some fields.  Change
        it to strtoul().
        
        If a casted length is too long, raise an error.
      sql/share/errmsg.txt:
        Change ER_TOO_BIG_FIELDLENGTH so that it can accept sizes larger
        than 2**15 -- instead, 2**32.
      sql/sql_yacc.yy:
        Make lengths take, in addition to NUM, LONG_NUM, ULONGLONG_NUM,
        and DECIMAL_NUM.
      sql/unireg.h:
        Define new constant.
      13fea36d
  17. 06 Aug, 2007 1 commit
    • unknown's avatar
      Bug #29536: timestamp inconsistent in replication around 1970 · 1f83b351
      unknown authored
      MySQL replicates the time zone only when operations that involve
      it are performed. This is controlled by a flag. But this flag
      is set only on successful operation.
      The flag must be set also when there is an error that involves
      a timezone (so the master would replicate the error to the slaves). 
      
      Fixed by moving the setting of the flag before the operation
      (so it apples to errors as well).
      
      
      mysql-test/r/rpl_timezone.result:
        Bug #29536: test case
      mysql-test/t/rpl_timezone.test:
        Bug #29536: test case
      sql/field.cc:
        Bug #29536: move setting of the flag before the operation
        (so it apples to errors as well).
      sql/time.cc:
        Bug #29536: move setting of the flag before the operation
        (so it apples to errors as well).
      1f83b351
  18. 23 Jul, 2007 1 commit
    • unknown's avatar
      Fixed bug #29611. · d50caace
      unknown authored
      If a primary key is defined over column c of enum type then 
      the EXPLAIN command for a look-up query of the form
        SELECT * FROM t WHERE c=0
      said that the query was with an impossible where condition though the
      query correctly returned non-empty result set when the table indeed 
      contained rows with error empty strings for column c. 
      
      This kind of misbehavior was due to a bug in the function 
      Field_enum::store(longlong,bool) that erroneously returned 1 if
      the the value to be stored was equal to 0. 
      Note that the method 
      Field_enum::store(const char *from,uint length,CHARSET_INFO *cs)
      correctly returned 0 if a value of the error empty string 
      was stored. 
      
      
      mysql-test/r/type_enum.result:
        Added a test case for bug #29661.
      mysql-test/t/type_enum.test:
        Added a test case for bug #29661.
      sql/field.cc:
        Fixed bug #29611.
        If a primary key was defined over column c of enum type then 
        the EXPLAIN command for a look-up query of the form
          SELECT * FROM t WHERE c=0
        said that the query was with an impossible where condition though the
        query correctly returned non-empty result set when the table indeed 
        contained rows with error empty strings for column c. 
        
        This kind of misbehavior was due to a bug in the function 
        Field_enum::store(longlong,bool) that erroneously returned 1 if
        the the value to be stored was equal to 0. 
        Note that the method 
        Field_enum::store(const char *from,uint length,CHARSET_INFO *cs)
        correctly returned 0 if a value of the error empty string 
        was stored.
      d50caace
  19. 19 Jul, 2007 1 commit
    • unknown's avatar
      field.cc, field.h: · 9fa66ba4
      unknown authored
        i5 compatibility
      
      
      sql/field.h:
        i5 compatibility
      sql/field.cc:
        i5 compatibility
      9fa66ba4
  20. 14 Jul, 2007 1 commit
    • unknown's avatar
      Bug#29729: Wrong conversion error led to an empty result set. · 4f146f65
      unknown authored
      The Field_newdate::store when storing a DATETIME value was returning the
      'value was cut' error even if the thd->count_cuted_fields flag is set to
      CHECK_FIELD_IGNORE. This made range optimizr think that there is no
      appropriate data in the table and thus to return an empty set.
      
      Now the Field_newdate::store function returns conversion error only if the
      thd->count_cuted_fields flag isn't set to CHECK_FIELD_IGNORE.
      
      
      mysql-test/t/type_time.test:
        Added a test case for the bug#29729: Wrong conversion error led to an empty result set.
      mysql-test/r/type_time.result:
        Added a test case for the bug#29729: Wrong conversion error led to an empty result set.
      sql/field.cc:
        Bug#29729: Wrong conversion error led to an empty result set.
      4f146f65
  21. 07 Jul, 2007 1 commit
    • unknown's avatar
      Fixed bug #29417. · 0671e30a
      unknown authored
      An assertion abort could occur for some grouping queries that employed 
      decimal user variables with assignments to them.
      
      The problem appeared the constructors of the class Field_new_decimal
      because the function my_decimal_length_to_precision did not guarantee
      returning decimal precision not greater than DECIMAL_MAX_PRECISION.
      
      
      mysql-test/r/type_newdecimal.result:
        Added a test case for bug #29417.
      mysql-test/t/type_newdecimal.test:
        Added a test case for bug #29417.
      sql/field.cc:
        Fixed bug #29417.
        An assertion abort could occur for some grouping queries that employed 
        decimal user variables with assignments to them.
        
        The problem appeared the constructors of the class Field_new_decimal
        because the function my_decimal_length_to_precision did not guarantee
        returning decimal precision not greater than DECIMAL_MAX_PRECISION.
        
        Now if the precision returned by calls to my_decimal_length_to_precision
        in the constructors of the class Field_new_decimal is greater than 
        DECIMAL_MAX_PRECISION the precision is set to this value.
      0671e30a
  22. 20 Jun, 2007 1 commit
    • unknown's avatar
      configure.in: · aeddf24a
      unknown authored
        Added --with-system-type=<systype> and --with-machine-type=<machtype>
        options, to be able to override the one detected, for --version strings
      field.cc, field.h, listener.cc:
        C++ compatibility change for IBM VisualAge 6 and i5/OS
      
      
      configure.in:
        Added --with-system-type=<systype> and --with-machine-type=<machtype>
        options, to be able to override the one detected, for --version strings
      server-tools/instance-manager/listener.cc:
        C++ compatibility change for IBM VisualAge 6 and i5/OS
      sql/field.cc:
        C++ compatibility change for IBM VisualAge 6 and i5/OS
      sql/field.h:
        C++ compatibility change for IBM VisualAge 6 and i5/OS
      aeddf24a
  23. 07 Jun, 2007 2 commits
    • unknown's avatar
      Fix for BUG#27592: stack overrun when storing datetime value · 727757d2
      unknown authored
      using prepared statements.
      
      
      sql/field.cc:
        Using MAX_DATETIME_WIDTH or MAX_DATETIME_COMPRESSED_WIDTH
        constants for the length of DATETIME fields.
        
        Using MAX_DATE_STRING_REP_LENGTH for allocating buffers
        for date/time/... string representation.
      sql/item_timefunc.cc:
        Using MAX_DATETIME_WIDTH or MAX_DATETIME_COMPRESSED_WIDTH
        constants for the length of DATETIME fields.
        
        Using MAX_DATE_STRING_REP_LENGTH for allocating buffers
        for date/time/... string representation.
      sql/unireg.h:
        Introduce a constant for length of datetime compressed
        format (YYYYMMDDHHMMSS).
      727757d2
    • unknown's avatar
      Bug#28878: InnoDB tables with UTF8 character set and indexes cause · 970b26e6
      unknown authored
      wrong result for DML
      When making key reference buffers over CHAR fields whitespace (0x20) 
      must be used to fill in the remaining space in the field's buffer.
      This is what Field_string::store() does.
      Fixed Field_string::get_key_image() to do the same.
      
      
      mysql-test/r/innodb_mysql.result:
        Bug#28878: test case
      mysql-test/t/innodb_mysql.test:
        Bug#28878: test case
      sql/field.cc:
        Bug#28878: Fill with space instead of binary zeros.
      970b26e6
  24. 30 May, 2007 1 commit
    • unknown's avatar
      Bug#28729: Field_enum wrongly reported an error while storing an empty string. · a7cf92bb
      unknown authored
      ENUM fields internally store their values as integers and may use integer
      values as indexes to their values. Invalid values are mapped to zero value.
      When storing an empty string the ENUM field fails to find an appropriate value
      and tries to convert the provided string to integer. The conversion also
      fails and error is returned even if the thd->count_cuted_fields is set to
      CHECK_FIELD_IGNORE. This makes the range optimizer wrongly decide that an
      impossible range is present.
      
      Now the Field_enum::store() returns error while storing an empty string only
      if the thd->count_cuted_fields isn't set to CHECK_FIELD_IGNORE.
      
      
      sql/field.cc:
        Bug#28729: Field_enum wrongly reported an error while storing an empty string.
        Now the Field_enum::store() returns error while storing an empty string only
        if the thd->count_cuted_fields isn't set to CHECK_FIELD_IGNORE.
      mysql-test/r/type_enum.result:
        Added a test case for the bug#28729: Field_enum wrongly reported an error
        while storing an empty string.
      mysql-test/t/type_enum.test:
        Added a test case for the bug#28729: Field_enum wrongly reported an error
        while storing an empty string.
      a7cf92bb
  25. 28 May, 2007 2 commits
    • unknown's avatar
      Some Windows-related fixes to make Microsoft compilers happy. This is for bug #28128. · 088cb9dd
      unknown authored
      include/m_string.h:
        Reduced the number of elements in log_10[] and log_01[] to not exceed DBL_MAX.
      sql/field.cc:
        Avoid the warning on Windows.
      strings/strtod.c:
        Reduced the number of elements in log_10[] and log_01[] to not exceed DBL_MAX.
      088cb9dd
    • unknown's avatar
      Fix for bug #28121 "INSERT or UPDATE into DOUBLE(200,0) field being truncated to 31 digits" · e3af3c21
      unknown authored
      When storing a large number to a FLOAT or DOUBLE field with fixed length, it could be incorrectly truncated if the field's length was greater than 31.
      
      This patch also does some code cleanups to be able to reuse code which is common between Field_float::store() and Field_double::store().
      
      
      include/m_string.h:
        Added declarations for log_10 and log_01 from strtod.c
      mysql-test/r/type_float.result:
        Added the testcase for bug #28121 "INSERT or UPDATE into DOUBLE(200,0) field being truncated to 31 digits"
      mysql-test/t/type_float.test:
        Added the testcase for bug #28121 "INSERT or UPDATE into DOUBLE(200,0) field being truncated to 31 digits"
      sql/field.cc:
        Moved common code from Field_float::store() and Field_double:store() to Field_real::truncate()
        Fixed the algorithm to not truncate large input numbers if the field length is greater than 31.
        Fixed rounding to not depend on FLT_MAX/DBL_MAX constants.
      sql/field.h:
        Moved not_fixed member from Field_double to Field_real to allow code reuse between Field_float::store() and Field_double::store()
        Added truncate() method to Field_real which is used by both Field_float and Field_double
      sql/init.cc:
        log_10[] and log_01[] are now defined as statical arrays in strtod.c, no need to pre-computed them.
      sql/item_cmpfunc.cc:
        log_01[] now starts from 1e0, not from 1e-1 for consistency.
      sql/mysql_priv.h:
        Moved log_10[] and log_01[] from mysqld.cc to libmystrings.
      sql/mysqld.cc:
        Moved log_10[] and log_01[] from mysqld.cc to libmystrings.
      strings/strtod.c:
        Define and use log_10[] and log_01[] as static arrays of constants instead of values pre-computed at startup.
      e3af3c21
  26. 16 May, 2007 1 commit
    • unknown's avatar
      Backport of TIME->MYSQL_TIME / Y2K fixset · b5e4f54a
      unknown authored
         
      Made year 2000 handling more uniform
      Removed year 2000 handling out from calc_days()
      The above removes some bugs in date/datetimes with year between 0 and 200
      Now we get a note when we insert a datetime value into a date column
      For default values to CREATE, don't give errors for warning level NOTE
      Fixed some compiler failures
      Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support)
      Removed duplicate typedef TIME and replaced it with MYSQL_TIME
      
      Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE"
      Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value"
      Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
       
      
      
      include/my_time.h:
        Removed not used define YY_MAGIC_BELOW
        Added prototype for year_2000_handling()
      mysql-test/r/date_formats.result:
        Updated results (fixed bug in date_format() with year < 99
      mysql-test/r/func_sapdb.result:
        Added more testing of make_date()
      mysql-test/r/ps_2myisam.result:
        Now we get a note when we insert a datetime value into a date column
      mysql-test/r/ps_3innodb.result:
        Now we get a note when we insert a datetime value into a date column
      mysql-test/r/ps_4heap.result:
        Now we get a note when we insert a datetime value into a date column
      mysql-test/r/ps_5merge.result:
        Now we get a note when we insert a datetime value into a date column
      mysql-test/r/ps_7ndb.result:
        Now we get a note when we insert a datetime value into a date column
      mysql-test/r/strict.result:
        zero-year in str_to_date() throws warning in strict
      mysql-test/r/type_date.result:
        Added test for date conversions
      mysql-test/r/type_datetime.result:
        Added testcase for datetime to date conversion.
      mysql-test/t/date_formats.test:
        Added testing of dates < 200
      mysql-test/t/func_sapdb.test:
        More testing of makedate()
      mysql-test/t/type_date.test:
        Added test for date conversions
      mysql-test/t/type_datetime.test:
        Added testcase for datetime to date conversion
      sql/field.cc:
        Give note if we insert a datetime value in a date field
        Don't give notes if we are doing internal test conversions (like from convert_constant_item())
        More documentation (store functions can now return '3' to inform that the function did return a NOTE (not warning or error))
        Revert some changes in Field_newdate::store() to get more optimal code
        Field::set_warning() will now ignore notes if CHECK_FIELD_IGNORE is set.
        New parameters to make_truncated_value_warning()
      sql/field.h:
        Give note if we insert a datetime value in a date field
        Don't give notes if we are doing internal test conversions (like from convert_constant_item())
        More documentation (store functions can now return '3' to inform that the function did return a NOTE (not warning or error))
        Revert some changes in Field_newdate::store() to get more optimal code
        Field::set_warning() will now ignore notes if CHECK_FIELD_IGNORE is set.
        New parameters to make_truncated_value_warning()
      sql/item.cc:
        Give note if we insert a datetime value in a date field
        Don't give notes if we are doing internal test conversions (like from convert_constant_item())
        More documentation (store functions can now return '3' to inform that the function did return a NOTE (not warning or error))
        Revert some changes in Field_newdate::store() to get more optimal code
        Field::set_warning() will now ignore notes if CHECK_FIELD_IGNORE is set.
        New parameters to make_truncated_value_warning()
      sql/item.h:
        TIME -> MYSQL_TIME
      sql/item_cmpfunc.cc:
        Don't print notes in convert_constant_item()
      sql/item_func.h:
        TIME -> MYSQL_TIME
      sql/item_timefunc.cc:
        New parameters to make_truncated_value_warning()
        Moved year 2000 handling out from calc_days()
      sql/item_timefunc.h:
        TIME -> MYSQL_TIME
      sql/my_decimal.cc:
        TIME -> MYSQL_TIME
      sql/my_decimal.h:
        TIME -> MYSQL_TIME
      sql/mysql_priv.h:
        Added error level to make_truncated_value_warning()
      sql/protocol.cc:
        TIME -> MYSQL_TIME
      sql/protocol.h:
        TIME -> MYSQL_TIME
      sql/sp.cc:
        TIME -> MYSQL_TIME
      sql/sql_base.cc:
        Make testing of result value of save_in_field() uniform
      sql/sql_class.h:
        TIME -> MYSQL_TIME
      sql/sql_show.cc:
        TIME -> MYSQL_TIME
      sql/structs.h:
        TIME -> MYSQL_TIME
      sql/time.cc:
        Added error level to make_truncated_value_warning()
      sql/tztime.cc:
        TIME -> MYSQL_TIME
      sql/tztime.h:
        TIME -> MYSQL_TIME
      sql/unireg.cc:
        For default values to CREATE, don't give errors for warning level NOTE
        (Fixed failed CREATE when we give a datetime value to a date field)
      sql-common/my_time.c:
        Added year_2000_handling()
        Removed year 2000 handling from calc_daynr()
      b5e4f54a
  27. 09 May, 2007 1 commit
    • unknown's avatar
      Bug #27921 View ignores precision for CAST() · f2a52dd0
      unknown authored
      Item_decimal_typecast::print properly implemented
      
      
      mysql-test/r/view.result:
        Bug #27921 View ignores precision for CAST()
        test result
      mysql-test/t/view.test:
        Bug #27921 View ignores precision for CAST()
        test case
      sql/field.cc:
        zero decimals handling unified
      sql/item_create.cc:
        Bug #27921 View ignores precision for CAST()
        create_func_cast parameters changed, zero precision handling unified
      sql/item_create.h:
        Bug #27921 View ignores precision for CAST()
        create_func_cast parameters changed
      sql/item_func.cc:
        Bug #27921 View ignores precision for CAST() 
        Item_decimal_typecast::print properly implemented
      sql/item_func.h:
        Bug #27921 View ignores precision for CAST()
        max_length counting fixed
      sql/my_decimal.h:
        Bug #27921 View ignores precision for CAST()
        my_decimal_trim() implemented to unify zero precision handling
      sql/sql_yacc.yy:
        Bug #27921 View ignores precision for CAST()
        create_func_cast calls simplified
      f2a52dd0
  28. 28 Apr, 2007 1 commit
    • unknown's avatar
      Fixed bug #13191. · 98c0da4e
      unknown authored
      INSERT...ON DUPLICATE KEY UPDATE may cause error 1032: 
      "Can't find record in ..." if we are inserting into
      InnoDB table unique index of partial key with
      underlying UTF-8 string field.
      
      This error occurs because INSERT...ON DUPLICATE uses a wrong
      procedure to copy string fields of multi-byte character sets
      for index search.
      
      
      mysql-test/t/innodb_mysql.test:
        Added test case for bug #13191.
      mysql-test/r/innodb_mysql.result:
        Added test case for bug #13191.
      sql/field.h:
        Fixed bug #13191.
        Field_string::get_key_image() virtual function was overloaded
        to implement copying of variable length character (UTF-8) fields.
        Field::get_key_image() function prototype has been changed to
        return byte size of copied data.
      sql/field.cc:
        Fixed bug #13191.
        Field_string::get_key_image() virtual function was overloaded
        to implement copying of variable length character (UTF-8) fields.
        Field::get_key_image() function prototype has been changed to
        return byte size of copied data.
      sql/key.cc:
        Fixed bug #13191.
        INSERT...ON DUPLICATE KEY UPDATE may cause error 1032: 
        "Can't find record in ...".
        This error occurs because INSERT...ON DUPLICATE uses
        a wrong procedure to copy field parts for index search.
        key_copy() function has been fixed.
      98c0da4e
  29. 02 Apr, 2007 1 commit
    • unknown's avatar
      Bug#27069 set with identical elements are created · d03c7d2d
      unknown authored
      added the check for unique elements count in SET
      
      
      mysql-test/r/type_set.result:
        test result
      mysql-test/t/type_set.test:
        test case
      sql/field.cc:
        removed the check for elements count in SET
      sql/sql_table.cc:
        added the check for unique elements count in SET
      d03c7d2d
  30. 29 Mar, 2007 1 commit
    • unknown's avatar
      Fix for bugs · 86010101
      unknown authored
      #27176: Assigning a string to an year column has unexpected results
      #26359: Strings becoming truncated and converted to numbers under STRICT mode
      
      Problems: 
      1. storing a string to an integer field we don't check 
         if strntoull10rnd() returns MY_ERRNO_EDOM error.
         Fix: check for MY_ERRNO_EDOM.
      2. storing a string to an year field we use my_strntol() function.
         Fix: use strntoull10rnd() instead.
      
      
      mysql-test/r/strict.result:
        Fix for bugs
        #27176: Assigning a string to an year column has unexpected results
        #26359: Strings becoming truncated and converted to numbers under STRICT mode
          - test result.
      mysql-test/r/type_date.result:
        Fix for bugs
        #27176: Assigning a string to an year column has unexpected results
        #26359: Strings becoming truncated and converted to numbers under STRICT mode
          - test result.
      mysql-test/r/type_year.result:
        Fix for bugs
        #27176: Assigning a string to an year column has unexpected results
        #26359: Strings becoming truncated and converted to numbers under STRICT mode
          - test result.
      mysql-test/t/strict.test:
        Fix for bugs
        #27176: Assigning a string to an year column has unexpected results
        #26359: Strings becoming truncated and converted to numbers under STRICT mode
          - test case.
      mysql-test/t/type_year.test:
        Fix for bugs
        #27176: Assigning a string to an year column has unexpected results
        #26359: Strings becoming truncated and converted to numbers under STRICT mode
      sql/field.cc:
        Fix for bugs
        #27176: Assigning a string to an year column has unexpected results
        #26359: Strings becoming truncated and converted to numbers under STRICT mode
          - Field_num::get_int() method introduced. It converts a string to integer
            then check errors and bounds.
          - similar Field_tiny::store(const char...),  Field_short::store(const char...),
            Field_medium::store(const char...), Field_long::store(const char...)
            rewritten, now they just call Field_num::get_int() then store value returned.
          - Field_num::check_int() simplified.
          - Field_year::store(const char...) now uses strntoull10rnd() and properly checks
            errors returned.
      sql/field.h:
        Fix for bugs
        #27176: Assigning a string to an year column has unexpected results
        #26359: Strings becoming truncated and converted to numbers under STRICT mode
         - check_int() moved to Field_num.
         - get_int() introduced.
      86010101
  31. 14 Mar, 2007 1 commit
    • unknown's avatar
      Bug #26794: · a22f257e
      unknown authored
      Different set of conditions is used to verify
      the validity of index definitions over a GEOMETRY
      column in ALTER TABLE and CREATE TABLE. 
      The difference was on how sub-keys notion validity
      is checked.
      Fixed by extending the CREATE TABLE condition to
      support the cases allowed in ALTER TABLE.
      Made the SHOW CREATE TABLE not to display spatial
      indexes using the sub-key notion.
      
      
      mysql-test/r/alter_table.result:
        Bug #26794: test case
      mysql-test/r/gis-rtree.result:
        Bug #26794: fixed SHOW CREATE TABLE output.
      mysql-test/t/alter_table.test:
        Bug #26794: test case
      sql/field.cc:
        Bug #26794: Allow sub-keys for GEOMETRY
      sql/sql_show.cc:
        Bug #26794: Don't show sub-key notion 
         in SHOW CREATE TABLE for SPATIAL indexes.
      sql/sql_table.cc:
        Bug #26794: Allow sub-keys for GEOMETRY
      a22f257e
  32. 09 Mar, 2007 1 commit
    • unknown's avatar
      Polishing: use constants instead of magic numbers. · a0521cd7
      unknown authored
      include/my_global.h:
        Introduce constants to be used instead of magic numbers.
      sql/field.cc:
        Polishing: use contants instead of magic numbers.
      sql/ha_innodb.cc:
        Polishing: use contants instead of magic numbers.
      sql/handler.cc:
        Polishing: use contants instead of magic numbers.
      sql/item.cc:
        Polishing: use contants instead of magic numbers.
      sql/item.h:
        Polishing: use contants instead of magic numbers.
      sql/item_func.cc:
        Polishing: use contants instead of magic numbers.
      sql/item_subselect.cc:
        Polishing: use contants instead of magic numbers.
      sql/log_event.cc:
        Polishing: use contants instead of magic numbers.
      sql/sql_base.cc:
        Polishing: use contants instead of magic numbers.
      sql/sql_select.cc:
        Polishing: use contants instead of magic numbers.
      sql/sql_show.cc:
        Polishing: use contants instead of magic numbers.
      sql/sql_table.cc:
        Polishing: use contants instead of magic numbers.
      a0521cd7
  33. 02 Mar, 2007 1 commit
    • unknown's avatar
      Bug #21103: DATE column not compared as DATE · fed9bb98
      unknown authored
      If we compare two items A and B, with B being (a constant) of a
      larger type, then A gets promoted to B's type for comparison if
      it's a constant, function, or CAST() column, but B gets demoted
      to A's type if A is a (not explicitly CAST()) column. This is
      counter-intuitive and not mandated by the standard.
       
      Disabling optimisation where it would be lossy so field value
      will properly get promoted and compared as binary string (rather
      than as integers).
      
      
      mysql-test/include/ps_conv.inc:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Fix certain queries to still work.
      mysql-test/r/func_time.result:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Show that everything works as expected.
      mysql-test/r/ps_2myisam.result:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Fix certain queries to still work.
      mysql-test/r/ps_3innodb.result:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Fix certain queries to still work.
      mysql-test/r/ps_4heap.result:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Fix certain queries to still work.
      mysql-test/r/ps_5merge.result:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Fix certain queries to still work.
      mysql-test/r/ps_7ndb.result:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Fix certain queries to still work.
      mysql-test/t/func_time.test:
        Bug #21103: DATE column not compared as DATE
        
        When comparing a DATE field with a DATETIME constant, we now compare
        as DATETIMEs, not as DATEs.  Show that everything works as expected.
      sql/field.cc:
        Bug #21103: DATE column not compared as DATE
        
        #0 stores the date only as a 3-byte integer; save_in_field() in
        #1 saves 'this' in field's format (DATE), #2 "converts a constant
        item to an int and replaces the original item" -- consequently,
        this replaces the Item_string "2006-11-06 04:08:36.0" with the
        Item_int_with_ref 20061106.
        
        #0  Field_newdate::store (this=0x8d26880, from=0x8d5e658 "2006-11-06
        04:08:36.0", len=21, cs=0x88022c0) at field.cc:5344
        #1  0x0817e3b0 in Item_string::save_in_field (this=0x8d5e670, field=0x8d26880, no_conversions=true) at item.cc:4340
        #2  0x081b22ae in convert_constant_item (thd=0x8d25240, field=0x8d26880, item=0x8d5e74c) at item_cmpfunc.cc:245
        #3  0x081b8a36 in Item_bool_func2::fix_length_and_dec (this=0x8d5e6f8) at item_cmpfunc.cc:309
        #4  0x081a3427 in Item_func::fix_fields (this=0x8d5e6f8, thd=0x8d25240, ref=0x8d5f5fc) at item_func.cc:190
        #5  0x0825bc2d in setup_conds (thd=0x8d25240, tables=0x8d5e410, leaves=0x8d5e410, conds=0x8d5f5fc) at sql_base.cc:4941
        ...
        
        Disabling optimisation where it would be lossy so field value will
        properly get promoted and compared as binary string (rather than as
        integers).
      fed9bb98
  34. 28 Feb, 2007 1 commit
    • unknown's avatar
      Fixed compiler warnings. · def9c0b2
      unknown authored
      client/mysql_upgrade.c:
        Fixed problem with mysql_upgrade being dependent
        on local my.cnf files and problem with memory not being freed.
      client/mysqltest.c:
        Changed type to avoid warning.
      cmd-line-utils/readline/xmalloc.c:
        Fix to avoid warning.
      include/my_dbug.h:
        To disable parts from code in non-debug more.
      sql/field.cc:
        Fixed warning.
      sql/ha_archive.cc:
        Fixed warning.
      sql/ha_berkeley.cc:
        Added casts to avoid warnings.
      sql/ha_ndbcluster.cc:
        Fixed warnings.
      sql/log.cc:
        Added casts to avoid warnings.
      sql/slave.cc:
        Avoid warning.
      sql/sql_repl.cc:
        Avoid warning.
      support-files/compiler_warnings.supp:
        Added disabled warnings to compiler_warnings.supp file.
        These are backported mainly from 5.1 suppress file, but there
        are some additional new ones.
      def9c0b2
  35. 31 Jan, 2007 1 commit
    • unknown's avatar
      fix for bug #19690: ORDER BY eliminates rows from the result · faad7355
      unknown authored
      Depending on the queries we use different data processing methods
      and can lose some data in case of double (and decimal in 4.1) fields.
      
      The fix consists of two parts:
      1. double comparison changed, now double a is equal to double b 
      if (a-b) is less than 5*0.1^(1 + max(a->decimals, b->decimals)). 
      For example, if a->decimals==1, b->decimals==2, a==b if (a-b)<0.005
      2. if we use a temporary table, store double values there as is 
      to avoid any data conversion (rounding).
      
      
      mysql-test/r/type_float.result:
        fix for bug #19690: ORDER BY eliminates rows from the result
          - test result
      mysql-test/t/type_float.test:
        fix for bug #19690: ORDER BY eliminates rows from the result
          - test case
      sql/field.cc:
        fix for bug #19690: ORDER BY eliminates rows from the result
          - use not_fixed flag instead of dec to check bounds.
      sql/field.h:
        fix for bug #19690: ORDER BY eliminates rows from the result
          - Field_Double::not_fixed flag introduced, which is set if dec == NOT_FIXED_DEC
            and is used in the ::store() to check bounds. 
          - new constructor introduced (with not_fixed_arg parameter).
      sql/init.cc:
        fix for bug #19690: ORDER BY eliminates rows from the result
          - fill log_01[] array with 0.1 powers.
      sql/item_cmpfunc.cc:
        fix for bug #19690: ORDER BY eliminates rows from the result
          - compare_real_fixed() and compare_e_real_fixed() introduced,
            they consider double a == double b if a-b is less than 'precision',
            'precision' is set to 5*0.1^(1 + max(a->decimals, b->decimals)), 
            for example, if a->decimals==1, b->decimals==2, 'precision' is 0.005
          - use the above functions if both arguments are fixed.
      sql/item_cmpfunc.h:
        fix for bug #19690: ORDER BY eliminates rows from the result
          - Arg_comparator::presision introduced.
          - Arg_comparator::compare_real_fixed(), Arg_comparator::compare_e_real_fixed() introduced.
      sql/mysql_priv.h:
        fix for bug #19690: ORDER BY eliminates rows from the result
          - log_01 array of 0.1 powers added.
      sql/mysqld.cc:
        fix for bug #19690: ORDER BY eliminates rows from the result
          - log_01 array of 0.1 powers added.
      sql/sql_select.cc:
        fix for bug #19690: ORDER BY eliminates rows from the result
          - if we create double field in a temporary table, set not_fixed flag
            (use proper constructor) to avoid data conversion 
            in the Field_double::store(). Otherwise we can lose some data.
      faad7355