An error occurred fetching the project authors.
- 06 May, 2008 1 commit
-
-
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.
-
- 10 Apr, 2008 1 commit
-
-
unknown authored
sql/field.cc: Fix indentation of new line.
-
- 09 Apr, 2008 1 commit
-
-
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.
-
- 08 Feb, 2008 1 commit
-
-
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.
-
- 06 Feb, 2008 1 commit
-
-
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.
-
- 13 Dec, 2007 1 commit
-
-
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
-
- 11 Dec, 2007 2 commits
-
-
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.
-
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.
-
- 02 Dec, 2007 1 commit
-
-
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.
-
- 01 Dec, 2007 3 commits
-
-
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.
-
unknown authored
Fixed the build failure on Windows. It does not have trunc() defined in math.h, so we should not use it code.
-
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().
-
- 13 Nov, 2007 1 commit
-
-
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
-
- 19 Oct, 2007 1 commit
-
-
unknown authored
-
- 18 Oct, 2007 1 commit
-
-
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
-
- 10 Oct, 2007 1 commit
-
-
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
-
- 04 Oct, 2007 1 commit
-
-
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.
-
- 28 Sep, 2007 1 commit
-
-
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.
-
- 31 Aug, 2007 1 commit
-
-
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.
-
- 06 Aug, 2007 1 commit
-
-
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).
-
- 23 Jul, 2007 1 commit
-
-
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.
-
- 19 Jul, 2007 1 commit
-
-
unknown authored
i5 compatibility sql/field.h: i5 compatibility sql/field.cc: i5 compatibility
-
- 14 Jul, 2007 1 commit
-
-
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.
-
- 07 Jul, 2007 1 commit
-
-
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.
-
- 20 Jun, 2007 1 commit
-
-
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
-
- 07 Jun, 2007 2 commits
-
-
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).
-
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.
-
- 30 May, 2007 1 commit
-
-
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.
-
- 28 May, 2007 2 commits
-
-
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.
-
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.
-
- 16 May, 2007 1 commit
-
-
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()
-
- 09 May, 2007 1 commit
-
-
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
-
- 28 Apr, 2007 1 commit
-
-
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.
-
- 02 Apr, 2007 1 commit
-
-
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
-
- 29 Mar, 2007 1 commit
-
-
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.
-
- 14 Mar, 2007 1 commit
-
-
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
-
- 09 Mar, 2007 1 commit
-
-
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.
-
- 02 Mar, 2007 1 commit
-
-
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).
-
- 28 Feb, 2007 1 commit
-
-
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.
-
- 31 Jan, 2007 1 commit
-
-
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.
-