'SELECT DISTINCT a,b FROM t1' should not use temp table if there is unique
index (or primary key) on a.
There are a number of other similar cases that can be calculated without the
use of a temp table : multi-part unique indexes, primary keys or using GROUP BY
instead of DISTINCT.
When a GROUP BY/DISTINCT clause contains all key parts of a unique
index, then it is guaranteed that the fields of the clause will be
unique, therefore we can optimize away GROUP BY/DISTINCT altogether.
This optimization has two effects:
* there is no need to create a temporary table to compute the
GROUP/DISTINCT operation (or the temporary table will be smaller if only GROUP
is removed and DISTINCT stays or if DISTINCT is removed and GROUP BY stays)
* this causes the statement in effect to become updatable in Connector/Java
because the result set columns will be direct reference to the primary key of
the table (instead to the temporary table that it currently references).
Implemented a check that will optimize away GROUP BY/DISTINCT for queries like
the above.
Currently it will work only for single non-constant table in the FROM clause.
mysql-test/r/distinct.result:
Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
- test case
mysql-test/t/distinct.test:
Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
- test case
sql/sql_select.cc:
Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
- disable GROUP BY if contains the fields of a unique index.
An UNIQUE KEY consisting of NOT NULL columns
was displayed as PRIMARY KEY in "DESC t1".
According to the code, that was intentional
behaviour for some reasons unknown to me.
This code was written before bitkeeper time,
so I cannot check who and why made this.
After discussing on dev-public, a decision
was made to remove this code
mysql-test/r/key.result:
Adding test case.
mysql-test/t/key.test:
Adding test case.
sql/table.cc:
Removing old wrong code
This was another manifestation of the problems fixed in the
patch for bug 16674.
Wrong calculation of length of the search prefix in the pattern
string led here to a wrong result set for a query in 4.1.
The bug could be demonstrated for any multi-byte character set.
mysql-test/r/ctype_utf8.result:
Added a test case for bug #18359.
mysql-test/t/ctype_utf8.test:
Added a test case for bug #18359.
Server crashed in some cases when a query required a MIN/MAX
agrregation for a 'ucs2' field.
In these cases the aggregation caused calls of the function
update_tmptable_sum_func that indirectly invoked
the method Item_sum_hybrid::min_max_update_str_field()
containing a call to strip_sp for a ucs2 character set.
The latter led directly to the crash as it used my_isspace
undefined for the ucs2 character set.
Actually the call of strip_sp is not needed at all in this
situation and has been removed by the fix.
mysql-test/r/ctype_ucs.result:
Added a test case for bug #20076.
mysql-test/t/ctype_ucs.test:
Added a test case for bug #20076.
The AsBinary function returns VARCHAR data type with binary collation.
It can cause problem for clients that treat that kind of data as
different from BLOB type.
So now AsBinary returns BLOB.
mysql-test/r/gis.result:
result fixed
mysql-test/t/gis.test:
test case added
sql/item_geofunc.h:
Now we return MYSQL_TYPE_BLOB for asBinary function
This bug in Field_string::cmp resulted in a wrong comparison
with keys in partial indexes over multi-byte character fields.
Given field a is declared as a varchar(16) collate utf8_unicode_ci
INDEX(a(4)) gives us an example of such an index.
Wrong key comparisons could lead to wrong result sets if
the selected query execution plan used a range scan by
a partial index over a utf8 character field.
This also caused wrong results in many other cases.
mysql-test/t/ctype_utf8.test:
Added test cases for bug #14896.
mysql-test/r/ctype_utf8.result:
Added test cases for bug #14896.
sql/field.cc:
Fixed bug #14896.
This bug in Field_string::cmp resulted in a wrong comparison
with keys in partial indexes over multi-byte character fields.
Given field a is declared as a varchar(16) collate utf8_unicode_ci
INDEX(a(4)) gives us an example of such an index.
Wrong key comparisons could lead to wrong result sets if
the selected query execution plan used a range scan by
a partial index over a utf8 character field.
This also caused wrong results in many other cases.
functions in queries
Using MAX()/MIN() on table with disabled indexes (by ALTER TABLE)
results in error 124 (wrong index) from storage engine.
The problem was that optimizer use disabled index to optimize
MAX()/MIN(). Normally it must skip disabled index and perform
table scan.
This patch skips disabled indexes for min/max optimization.
mysql-test/r/myisam.result:
Test case for BUG#20357.
mysql-test/t/myisam.test:
Test case for BUG#20357.
sql/opt_sum.cc:
Skip disabled/ignored indexes for min/max optimization.
The length of the prefix of the pattern string in the LIKE predicate that
determined the index range to be scanned was calculated incorrectly for
multi-byte character sets.
As a result of this in 4. 1 the the scanned range was wider then necessary
if the prefix contained not only one-byte characters.
In 5.0 additionally it caused missing some rows from the result set.
mysql-test/r/ctype_utf8.result:
Added test cases for bug #16674.
mysql-test/t/ctype_utf8.test:
Added test cases for bug #16674.
strings/ctype-mb.c:
Fixed bug #16674.
The length of the prefix of the pattern string in the LIKE predicate that
determined the index range to be scanned was calculated incorrectly for
multi-byte character sets.
As a result of this in 4. 1 the the scanned range was wider then necessary
if the prefix contained not only one-byte characters.
In 5.0 additionally it caused missing some rows from the result set.
The function my_like_range_mb was fixed to calculate the length of
the prefix in a pattern string correctly in all cases.
Added test case for bug#18759 Incorrect string to numeric conversion.
select.test:
Added test case for bug#18759 Incorrect string to numeric conversion.
item_cmpfunc.cc:
Cleanup after fix for bug#18360 removal
sql/item_cmpfunc.cc:
Cleanup after fix for bug#18360 removal
mysql-test/t/select.test:
Added test case for bug#18759 Incorrect string to numeric conversion.
mysql-test/r/select.result:
Added test case for bug#18759 Incorrect string to numeric conversion.
Reverted fix for bug#18360
mysql-test/t/func_in.test:
Reverted fix for bug#18360
mysql-test/r/func_in.result:
Reverted fix for bug#18360
sql/item_cmpfunc.cc:
Reverted fix for bug#18360
tables
Currently in INSERT ... SELECT ... LIMIT ... the compiler uses a
temporary table to store the results of SELECT ... LIMIT .. and then
uses that table as a source for INSERT. The problem is that in some cases
it actually skips the LIMIT clause in doing that and materializes the
whole SELECT result set regardless of the LIMIT.
This fix is limiting the process of filling up the temp table with only
that much rows that will be actually used by propagating the LIMIT value.
mysql-test/r/insert_select.result:
* Bug #9676: INSERT INTO x SELECT .. FROM x LIMIT 1; slows down with big
tables
- a test demonstrating the code path
mysql-test/t/insert_select.test:
* Bug #9676: INSERT INTO x SELECT .. FROM x LIMIT 1; slows down with big
tables
- a test demonstrating the code path
sql/sql_select.cc:
* Bug #9676: INSERT INTO x SELECT .. FROM x LIMIT 1; slows down with big
tables
- pass through the real LIMIT number if the temp table is created for
buffering results.
- set the counter for all the cases when the temp table is not used for
grouping
Certain updates of table joined to self results in unexpected
behavior.
The problem was that record cache was mistakenly enabled for
self-joined table updates. Normally record cache must be disabled
for such updates.
Fixed wrong condition in code that determines whether to use
record cache for self-joined table updates.
Only MyISAM tables were affected.
mysql-test/r/myisam.result:
Test case for BUG#18036.
mysql-test/t/myisam.test:
Test case for BUG#18036.
sql/sql_update.cc:
Fixed wrong condition in code that determines whether to use
record cache for self-joined table updates.
- make sure to disable bulk insert when check for duplicate key is needed
mysql-test/r/ndb_loaddatalocal.result:
New BitKeeper file ``mysql-test/r/ndb_loaddatalocal.result''
mysql-test/t/ndb_loaddatalocal.test:
New BitKeeper file ``mysql-test/t/ndb_loaddatalocal.test''
Problem: cast to unsigned limited result to
max signed bigint 9223372036854775808,
instead of max unsigned bigint 18446744073709551615.
Fix: don't use args[0]->val_int() when casting from
a floating point number, use val() instead, with range checkings,
special to unsigned data type.
item_func.cc:
Special handling of cast from REAL_RESULT
to unsigned int: we cannot execute args[0]->val_int()
because it cuts max allowed value to LONGLONG_INT,
instead of ULONGLONG_INT required.
count_distinct3.test:
Getting rid of "Data truncated; out of range ..." warnings.
cast.test, cast.result:
Adding test case.
ps.result:
Fixing that cast from 6570515219.6535
to unsigned didn't round to 6570515220,
and returned 6570515219 instead.
mysql-test/r/cast.result:
Adding test case.
mysql-test/r/ps.result:
Fixing that cast from 6570515219.6535
to unsigned didn't round to 6570515220,
and returned 6570515219 instead.
mysql-test/t/cast.test:
Adding test case.
mysql-test/t/count_distinct3.test:
Get rid of "wring unsigned value"
warnings.
sql/item_func.cc:
Special handling of cast from REAL)RESULT
to unsigned int: we cannot execute args[0]->val_int()
because it cuts max allowed value to LONGLONG_INT,
instead of ULONGLONG_INT required.
can lead to a wrong result.
All date/time functions has the STRING result type thus their results are
compared as strings. The string date representation allows a user to skip
some of leading zeros. This can lead to wrong comparison result if a date/time
function result is compared to such a string constant.
The idea behind this bug fix is to compare results of date/time functions
and data/time constants as ints, because that date/time representation is
more exact. To achieve this the agg_cmp_type() is changed to take in the
account that a date/time field or an date/time item should be compared
as ints.
This bug fix is partially back ported from 5.0.
The agg_cmp_type() function now accepts THD as one of parameters.
In addition, it now checks if a date/time field/function is present in the
list. If so, it tries to coerce all constants to INT to make date/time
comparison return correct result. The field for the constant coercion is
taken from the Item_field or constructed from the Item_func. In latter case
the constructed field will be freed after conversion of all constant items.
Otherwise the result is same as before - aggregated with help of the
item_cmp_type() function.
From the Item_func_between::fix_length_and_dec() function removed the part
which was converting date/time constants to int if possible. Now this is
done by the agg_cmp_type() function.
The new function result_as_longlong() is added to the Item class.
It indicates that the item is a date/time item and result of it can be
compared as int. Such items are date/time fields/functions.
Correct val_int() methods are implemented for classes Item_date_typecast,
Item_func_makedate, Item_time_typecast, Item_datetime_typecast. All these
classes are derived from Item_str_func and Item_str_func::val_int() converts
its string value to int without regard to the date/time type of these items.
Arg_comparator::set_compare_func() and Arg_comparator::set_cmp_func()
functions are changed to substitute result type of an item with the INT_RESULT
if the item is a date/time item and another item is a constant. This is done
to get a correct result of comparisons like date_time_function() = string_constant.
mysql-test/r/cast.result:
Fixed wrong test case result after bug fix#16377.
sql/item_timefunc.h:
Fixed bug#16377: result of DATE/TIME functions were compared as strings which
can lead to a wrong result.
The result_as_longlong() function is set to return TRUE for these classes:
Item_date, Item_date_func, Item_func_curtime, Item_func_sec_to_time,
Item_date_typecast, Item_time_typecast, Item_datetime_typecast,
Item_func_makedate.
sql/item_timefunc.cc:
Fixed bug#16377: result of DATE/TIME functions were compared as strings which
can lead to a wrong result.Correct val_int() methods are implemented for classes Item_date_typecast,
Item_func_makedate, Item_time_typecast, Item_datetime_typecast.
sql/item_cmpfunc.h:
Fixed bug#16377: result of DATE/TIME functions were compared as strings which
can lead to a wrong result.
Arg_comparator::set_compare_func() and Arg_comparator::set_cmp_func()
functions are changed to substitute result type of an item with the INT_RESULT
if the item is a date/time item and another item is a constant.
sql/field.cc:
Fixed bug#16377: result of DATE/TIME functions were compared as strings which
can lead to a wrong result.
Field::set_warning(), Field::set_datetime_warning() now use current_thd to get thd if table isn't set.
sql/item_cmpfunc.cc:
Fixed bug#16377: result of DATE/TIME functions were compared as strings which
can lead to a wrong result.
The agg_cmp_type() function now accepts THD as one of parameters.
In addition, it now checks if a date/time field/function is present in the
list. If so, it tries to coerce all constants to INT to make date/time
comparison return correct result. The field for the constant coercion is
taken from the Item_field or constructed from the Item_func. In latter case
the constructed field will be freed after conversion of all constant items.
Otherwise the result is same as before - aggregated with help of the
item_cmp_type() function.
sql/item.h:
The new function result_as_longlong() is added to the Item class.
It indicates that the item is a date/time item and result of it can be
compared as int. Such items are date/time fields/functions.
mysql-test/t/func_time.test:
Added test case fot bug#16377: result of DATE/TIME functions were compared as strings which
can lead to a wrong result.
mysql-test/r/func_time.result:
Added test case fot bug#16377: result of DATE/TIME functions were compared as strings which
can lead to a wrong result.
mysql-test/r/func_str.result:
Fix for bug #12728: Very strange behaviour of ELT
- test case
mysql-test/t/func_str.test:
Fix for bug #12728: Very strange behaviour of ELT
- test result
sql/item_strfunc.cc:
Fix for bug #12728: Very strange behaviour of ELT
- Item_func_elt::eq() introduced: check 'item' member as well
(to distinguish for instance elt(1, 'a', 'b') and elt(2, 'a', 'b')
sql/item_strfunc.h:
Fix for bug #12728: Very strange behaviour of ELT
- Item_func_elt::eq() introduced: check 'item' member as well
(to distinguish for instance elt(1, 'a', 'b') and elt(2, 'a', 'b')
mysql-test/mysql-test-run.pl:
Found when fixing bug#20303: The "usage()" function ignored the message it was given,
so we got no real indication about the problem. Print it if one is given.
mysql-test/mysql-test-run.pl:
A fix for bug#20303 "mysql-test-run.pl: Does not recognize -- argument":
Due to the use of 'pass_through' in option processing this lone '--' will remain
as an argument, it must be ignored explicitly.
mysql-test/r/auto_increment.result:
Fix for bug #6880: LAST_INSERT_ID() within a statement
- test result
mysql-test/r/rpl_log.result:
Fix for bug #6880: LAST_INSERT_ID() within a statement
- test result
mysql-test/t/auto_increment.test:
Fix for bug #6880: LAST_INSERT_ID() within a statement
- test case
mysql-test/t/rpl_log.test:
Fix for bug #6880: LAST_INSERT_ID() within a statement
- test case
sql/item_func.cc:
Fix for bug #6880: LAST_INSERT_ID() within a statement
- return the first thd->last_insert_id set (within a query)
into mysql.com:/usr/home/ram/work/4.1.b16546
sql/item_timefunc.cc:
Auto merged
mysql-test/r/func_time.result:
merging
mysql-test/t/func_time.test:
merging
The bug report revealed two problems related to min/max optimization:
1. If the length of a constant key used in a SARGable condition for
for the MIN/MAX fields is greater than the length of the field an
unwanted warning on key truncation is issued;
2. If MIN/MAX optimization is applied to a partial index, like INDEX(b(4))
than can lead to returning a wrong result set.
mysql-test/r/func_group.result:
Added test cases for bug #18206.
mysql-test/t/func_group.test:
Added test cases for bug #18206.
sql/opt_sum.cc:
Fixed bug #18206.
Suppressed the warning about data truncation when store_val_in_field
was used to store keys for the field used in MIN/MAX optimization.
Blocked MIN/MAX optimization for partial keys, such as in INDEX(b(4)).
sql/sql_select.cc:
Fixed bug #18206.
Added a parameter for the function store_val_in_field allowing to
control setting warnings about data truncation in the function.
sql/sql_select.h:
Fixed bug #18206.
Added a parameter for the function store_val_in_field allowing to
control setting warnings about data truncation in the function.
3.23 regression test failure
The member SEL_ARG::min_flag was not initialized,
due to which the condition for no GEOM_FLAG in function
key_or did not choose "Range checked for each record" as
the correct access method.
mysql-test/r/select.result:
testcase for 'Range checked' access method
mysql-test/t/select.test:
testcase for 'Range checked' access method
sql/opt_range.cc:
All of the class members initialized
The IN() function uses agg_cmp_type() to aggregate all types of its arguments
to find out some common type for comparisons. In this particular case the
char() and the int was aggregated to double because char() can contain values
like '1.5'. But all strings which do not start from a digit are converted to
0. thus 'a' and 'z' become equal.
This behaviour is reasonable when all function arguments are constants. But
when there is a field or an expression this can lead to false comparisons. In
this case it makes more sense to coerce constants to the type of the field
argument.
The agg_cmp_type() function now aggregates types of constant and non-constant
items separately. If some non-constant items will be found then their
aggregated type will be returned. Thus after the aggregation constants will be
coerced to the aggregated type.
mysql-test/t/func_in.test:
Added test case for bug#18360: Incorrect type coercion in IN() results in false comparison.
mysql-test/r/func_in.result:
Added test case for bug#18360: Incorrect type coercion in IN() results in false comparison.
sql/item_cmpfunc.cc:
Fixed bug#18360: Incorrect type coercion in IN() results in false comparison.
The agg_cmp_type() function now aggregates types of constant and non-constant
items separately. If some non-constant items will be found then their
aggregated type will be returned. Thus after the aggregation constants will
be coerced to the aggregated type.
In multi-table delete a table for delete can't be used for selecting in
subselects. Appropriate error was raised but wasn't checked which leads to a
crash at the execution phase.
The mysql_execute_command() now checks for errors before executing select
for multi-delete.
mysql-test/t/multi_update.test:
Added test case for bug#19225: unchecked error results in server crash
mysql-test/r/multi_update.result:
Added test case for bug#19225: unchecked error results in server crash
sql/sql_parse.cc:
Fixed bug#19225: unchecked error results in server crash
The mysql_execute_command() now checks for errors before executing select for multi-delete.
argument can lead to a wrong result.
md5() and sha() functions treat their arguments as case sensitive strings.
But when they are compared their arguments were compared as a case
insensitive strings which leads to two functions with different arguments
and thus different results to being identical. This can lead to a wrong
decision made in the range optimizer and thus lead to a wrong result set.
Item_func_md5::fix_length_and_dec() and Item_func_sha::fix_length_and_dec()
functions now set binary collation on their arguments.
sql/item_strfunc.cc:
Fixed bug#15351: Wrong collation used for comparison of md5() and sha()
argument can lead to a wrong result.
Item_func_md5::fix_length_and_dec() and Item_func_sha::fix_length_and_dec()
functions now set binary collation on their arguments.
mysql-test/r/func_str.result:
Added test case for the bug#15351: Wrong collation used for comparison of md5() and sha()
argument can lead to a wrong result.
mysql-test/t/func_str.test:
Added test case for the bug#15351: Wrong collation used for comparison of md5() and sha()
argument can lead to a wrong result.
refining the test case to exclude problems with koi8r on some platforms.
mysql-test/t/mysqlbinlog.test:
replacing unavailble on some platforms koi8r with latin1 still to preserve the essence of the testcase:
to generate utf8 names in binlog, despite client charset was different, and
to digest this binlog.
refers to a column name.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
include/mysqld_error.h:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
include/sql_state.h:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
mysql-test/r/explain.result:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
mysql-test/r/key_cache.result:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
mysql-test/r/preload.result:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
mysql-test/r/select.result:
Added a test case for bug #17873.
mysql-test/t/explain.test:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
mysql-test/t/select.test:
Added a test case for bug #17873.
sql/share/czech/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/danish/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/dutch/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/english/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/estonian/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/french/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/german/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/greek/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/hungarian/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/italian/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/japanese-sjis/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/japanese/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/korean/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/norwegian-ny/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/norwegian/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/polish/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/portuguese/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/romanian/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/russian/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/serbian/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/slovak/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/spanish/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/swedish/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
sql/share/ukrainian/errmsg.txt:
Fixed bug #17873.
Added a new error message ER_INDEX_DOES_NOT_EXIST.
The Item_func_concat::val_str() function tries to make as less re-allocations
as possible. This results in appending strings returned by 2nd and next
arguments to the string returned by 1st argument if the buffer for the first
argument has enough free space. A constant subselect is evaluated only once
and its result is stored in an Item_cache_str. In the case when the first
argument of the concat() function is such a subselect Item_cache_str returns
the stored value and Item_func_concat::val_str() append values of other
arguments to it. But for the next row the value in the Item_cache_str isn't
restored because the subselect is a constant one and it isn't evaluated second
time. This results in appending string values of 2nd and next arguments to the
result of the previous Item_func_concat::val_str() call.
The Item_func_concat::val_str() function now checks whether the first argument
is a constant one and if so it doesn't append values of 2nd and next arguments
to the string value returned by it.
mysql-test/t/func_concat.test:
Added test case for bug#16716: subselect in concat() may lead to a wrong result.
mysql-test/r/func_concat.result:
Added test case for bug#16716: subselect in concat() may lead to a wrong result.
sql/item_strfunc.cc:
Fixed bug#16716: subselect in concat() may lead to a wrong result.
The Item_func_concat::val_str() function now checks whether the first argument
is a constant one and if so it doesn't append values of 2nd and next arguments
to the string value returned by it.
into neptunus.(none):/home/msvensson/mysql/mysql-4.1
mysql-test/mysql-test-run.pl:
Auto merged
mysql-test/mysql-test-run.sh:
Auto merged
mysql-test/r/mysqldump.result:
Manual merge
mysql-test/t/mysqldump.test:
Manual merge
revert the fix for bug#8303
correct the test for bug#8378
mysql-test/r/ctype_sjis.result:
updated
mysql-test/t/ctype_sjis.test:
updated
sql/sql_lex.cc:
revert the fix for bug#8303
tests/mysql_client_test.c:
correct the test for bug#8378
fixing an issue with the test portability.
mysql-test/t/mysqlbinlog.test:
BUG#14157: utf8 encoding in binlog without set character_set_client
fixing koi8r specific case to run on all platforms. client does not announce in cmd line any specific
encoding but rather set it via `set names'.
client/mysqldump.c:
Fix for bug #18536: mysqldump does not maintain table orders as per --tables option
- use list to store table names instead of hash.
mysql-test/r/mysqldump.result:
Fix for bug #18536: mysqldump does not maintain table orders as per --tables option
- test result.
mysql-test/t/mysqldump.test:
Fix for bug #18536: mysqldump does not maintain table orders as per --tables option
- test case.
mysql-test/r/func_time.result:
Fix for #16327: invalid TIMESTAMP values retrieved
- test result
mysql-test/t/func_time.test:
Fix for #16327: invalid TIMESTAMP values retrieved
- test case
sql/field.cc:
Fix for #16327: invalid TIMESTAMP values retrieved
- let 1969 as well
fixing encoding example because of table names can not be in koi8r
on some platforms.
mysql-test/t/rpl_temporary.test:
koi8r encoding to name tables is changed for latin1 for the former does not work
on some platforms.
The effect of the test remains: a test table is named to have multibyte utf8 representation,
which is the essence of the bug.
- invalidate ndb dict cache on cluster disconnect (ClusterMgr.cpp)
- add check for correct frm on external lock when table cache is found invalid
ndb/include/ndbapi/ndb_cluster_connection.hpp:
Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/ClusterMgr.cpp:
Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/ClusterMgr.hpp:
Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/DictCache.cpp:
Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/DictCache.hpp:
Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/TransporterFacade.hpp:
Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/ndb_cluster_connection.cpp:
Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
ndb/src/ndbapi/ndb_cluster_connection_impl.hpp:
Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
sql/ha_ndbcluster.cc:
Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
mysql-test/r/ndb_autodiscover3.result:
Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
mysql-test/t/ndb_autodiscover3.test:
Bug #16875 Using stale MySQLD FRM files can cause restored cluster to fail
fixing names length. Got an issue when merged to 5.0, decided to fix starting from 4.1
mysql-test/t/mysqlbinlog.test:
fixing temp table name to fit to 64 bytes for 5.0
mysql-test/t/rpl_temporary.test:
fixing temp table name to fit to 64 bytes for 5.0
mysqltest program should be really multithreaded to perform this
test with the embedded server. So this test disabled until we
redo mysqltest this way
mysql-test/t/init_connect.test:
test can't work properly with the embedded server yet
fixing a path to find charset by $MYSQL client. I believe the fix is done what should be
by default.
mysql-test/t/mysqlbinlog.test:
--character-sets-dir=../sql/share/charsets is added otherwise client/.libs/lt-mysql
searches in /usr/local/mysql ... A bug?
mysql-test/t/rpl_temporary.test:
--character-sets-dir=../sql/share/charsets/
into mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/4.1
mysql-test/r/rpl_temporary.result:
Auto merged
mysql-test/t/rpl_temporary.test:
Auto merged
sql/sql_base.cc:
Auto merged
sql/mysql_priv.h:
manual merge, a comment added
A pattern to generate binlog for DROPped temp table in close_temporary_tables
was buggy: could not deal with a grave-accent-in-name table.
The fix exploits `append_identifier()' for quoting and duplicating accents.
mysql-test/r/rpl_temporary.result:
results changed
mysql-test/t/rpl_temporary.test:
more correct internal table emulation; typo of @@session in bug#17263.
sql/mysql_priv.h:
bool is_user_table(TABLE * table)
is added to answer wheather temporary table was created explicitly.
sql/sql_base.cc:
Utilizing `append_identifier' to quote. `close_temporary_tables' once again recoded
I hope to become much simplier than previously. No-binlog branch is separated completely the
rest that adopts String's methods.
- Check that length of value is longer than 1 before decrementing length by 2.
- Backport from 5.0, make it possible to use my_print_defaults in tests
mysql-test/mysql-test-run.pl:
Backport from 5.0, make it possible to use my_print_defaults from tests
mysql-test/mysql-test-run.sh:
Backport from 5.0, make it possible to use my_print_defaults from tests
mysql-test/r/mysqldump.result:
Update result
mysql-test/t/mysqldump.test:
Test that my_print default don't segfault when encountering an option without closing "
mysys/default.c:
Check that length of value is longer than 1 before deciding to decrement its length by 2.
mysql-test/std_data/bug15328.cnf:
New BitKeeper file ``mysql-test/std_data/bug15328.cnf''
Binlog lacks encoding info about DROPped temporary table.
Idea of the fix is to switch temporary to system_charset_info when a temporary table
is DROPped for binlog. Since that is the server, that automatically, but not the client, who generates the query
the binlog should be updated on the server's encoding for the coming DROP.
The `write_binlog_with_system_charset()' is introduced to replace similar problematic places in the code.
mysql-test/r/drop_temp_table.result:
results changed
mysql-test/r/mix_innodb_myisam_binlog.result:
results changed
mysql-test/r/mysqlbinlog.result:
results changed
mysql-test/r/rpl_temporary.result:
results changed
mysql-test/t/mysqlbinlog.test:
Check roll-forward recovery from binlog where there are DROP temporary tables created
in koi8r.
mysql-test/t/rpl_temporary.test:
Check slave digests binlog with DROP temporary tables created in koi8r.
sql/mysql_priv.h:
`write_binlog_with_system_charset()' is added to be called when a binlog event
is created "implicitly" like DROP temporary table is case of closing connection.
sql/sql_base.cc:
Idea of the fix is to switch temporary to system_charset_info when a temporary table
is DROPped for binlog. Since that is the server, not the client, who generates the query
the binlog should be updated on server's encoding for the coming DROP.
load_file() string-function should return NULL rather than throw an error if
the file doesn't exist, as per the manual.
mysql-test/t/outfile.test:
expect NULL rather than error if file given to load_file() doesn't exist
mysql-test/t/func_str.test:
show that load_file() will return NULL rather than throw an error
if file doesn't exist
mysql-test/r/outfile.result:
expect NULL rather than error if file given to load_file() doesn't exist
mysql-test/r/func_str.result:
expect NULL rather than error if file given to load_file() doesn't exist
sql/item_strfunc.cc:
load_file() should return NULL as per the docs if file not found,
rather than throw an error
A query with a group by and having clauses could return a wrong
result set if the having condition contained a constant conjunct
evaluated to FALSE.
It happened because the pushdown condition for table with
grouping columns lost its constant conjuncts.
Pushdown conditions are always built by the function make_cond_for_table
that ignores constant conjuncts. This is apparently not correct when
constant false conjuncts are present.
mysql-test/r/having.result:
Added a test case for bug #14927.
mysql-test/t/having.test:
Added a test case for bug #14927.
sql/sql_lex.cc:
Fixed bug #14927.
Initialized fields for having conditions in st_select_lex::init_query().
sql/sql_lex.h:
Fixed bug #14927.
Added a field to restore having condititions for execution in SP and PS.
sql/sql_prepare.cc:
Fixed bug #14927.
Added code to restore havinf conditions for execution in SP and PS.
sql/sql_select.cc:
Fixed bug #14927.
Performed evaluation of constant expressions in having clauses.
If the having condition contains a constant conjunct that is always false
an empty result set is returned after the optimization phase.
In this case the corresponding EXPLAIN command now returns
"Impossible HAVING" in the last column.
The bug was as follows: When merge_key_fields() encounters "t.key=X OR t.key=Y" it will
try to join them into ref_or_null access via "t.key=X OR NULL". In order to make this
inference it checks if Y<=>NULL, ignoring the fact that value of Y may be not yet known.
The fix is that the check if Y<=>NULL is made only if value of Y is known (i.e. it is a
constant).
TODO: When merging to 5.0, replace used_tables() with const_item() everywhere in merge_key_fields().
mysql-test/r/innodb_mysql.result:
Testcase for BUG16798
mysql-test/t/innodb_mysql.test:
Testcase for BUG16798
sql/sql_select.cc:
BUG#16798: Inapplicable ref_or_null query plan and bad query result on random occasions
In merge_key_fields() don't call val->is_null() if the value of val is not known.
The reason of the bug is in that `get_var_with_binlog' performs missed
assingment of
the variables as side-effect. Doing that it eventually calls
`free_underlaid_joins' to pass as an argument `thd->lex->select_lex' of the lex
which belongs to the user query, not
to one which is emulated i.e SET @var1:=NULL.
`get_var_with_binlog' is refined to supply a temporary lex to sql_set_variables's stack.
mysql-test/r/rpl_user_variables.result:
results changed
mysql-test/t/rpl_user_variables.test:
a problematic query to be binlogged is added
sql/item_func.cc:
BUG#19136: Crashing log-bin and uninitialized user variables
The reason of the bug is in that how `get_var_with_binlog' performs missed
assingment of the variables: `free_underlaid_joins' gets as an argument `thd->lex->select_lex'
which belongs to the user query, not to one which is emulated i.e SET @var1:=NULL.
`get_var_with_binlog' is refined to supply a temporary lex to sql_set_variables's stack.
TIME_FORMAT using "%l:%i" returns 36:00 with 24:00:00 in TIME column
mysql-test/r/date_formats.result:
Added test case for Bug#11324,
"TIME_FORMAT using "%l:%i" returns 36:00 with 24:00:00 in TIME column"
mysql-test/t/date_formats.test:
Added test case for Bug#11324,
"TIME_FORMAT using "%l:%i" returns 36:00 with 24:00:00 in TIME column"
Problem:
if a user was granted privileges on database "d1",
it also was able to act on "D1" (i.e. in upper case),
even on Unix with case sensitive file system.
Fix:
Initialize grant hash to use binary comparison
if lower_case_file_system is not set (on most unixes),
and case insensitive comparison otherwise (Windows, MacOSX).
sql/sql_acl.cc:
Initialize hash to use binary comparison with case sensitive FS.
mysql-test/include/have_case_sensitive_file_system.inc:
New BitKeeper file ``mysql-test/include/have_case_sensitive_file_system.inc''
Backporting from 5.1
mysql-test/r/case_sensitive_file_system.require:
New BitKeeper file ``mysql-test/r/case_sensitive_file_system.require''
Backporting from 5.1
mysql-test/r/lowercase_fs_off.result:
Adding test case
mysql-test/t/lowercase_fs_off.test:
Adding test case
mysqldump / SHOW CREATE TABLE will show the NEXT available value for
the PK, rather than the *first* one that was available (that named in
the original CREATE TABLE ... AUTO_INCREMENT = ... statement).
This should produce correct and robust behaviour for the obvious use
cases -- when no data were inserted, then we'll produce a statement
featuring the same value the original CREATE TABLE had; if we dump
with values, INSERTing the values on the target machine should set the
correct next_ID anyway (and if not, we'll still have our AUTO_INCREMENT =
... to do that). Lastly, just the CREATE statement (with no data) for
a table that saw inserts would still result in a table that new values
could safely be inserted to).
There seems to be no robust way however to see whether the next_ID
field is > 1 because it was set to something else with CREATE TABLE
... AUTO_INCREMENT = ..., or because there is an AUTO_INCREMENT column
in the table (but no initial value was set with AUTO_INCREMENT = ...)
and then one or more rows were INSERTed, counting up next_ID. This
means that in both cases, we'll generate an AUTO_INCREMENT =
... clause in SHOW CREATE TABLE / mysqldump. As we also show info on,
say, charsets even if the user did not explicitly give that info in
their own CREATE TABLE, this shouldn't be an issue.
As per above, the next_ID will be affected by any INSERTs that have
taken place, though. This /should/ result in correct and robust
behaviour, but it may look non-intuitive to some users if they CREATE
TABLE ... AUTO_INCREMENT = 1000 and later (after some INSERTs) have
SHOW CREATE TABLE give them a different value (say, CREATE TABLE
... AUTO_INCREMENT = 1006), so the docs should possibly feature a
caveat to that effect.
It's not very intuitive the way it works now (with the fix), but it's
*correct*. We're not storing the original value anyway, if we wanted
that, we'd have to change on-disk representation?
If we do dump/load cycles with empty DBs, nothing will change. This
changeset includes an additional test case that proves that tables
with rows will create the same next_ID for AUTO_INCREMENT = ... across
dump/restore cycles.
Confirmed by support as likely solution for client's problem.
mysql-test/r/auto_increment.result:
test for creation of AUTO_INCREMENT=... clause
mysql-test/r/gis-rtree.result:
Add AUTO_INCREMENT=... clauses where appropriate
mysql-test/r/mysqldump.result:
show that AUTO_INCREMENT=... will survive dump/restore cycles
mysql-test/r/symlink.result:
Add AUTO_INCREMENT=... clauses where appropriate
mysql-test/t/auto_increment.test:
test for creation of AUTO_INCREMENT=... clause
mysql-test/t/mysqldump.test:
show that AUTO_INCREMENT=... will survive dump/restore cycles
sql/sql_show.cc:
Add AUTO_INCREMENT=... to output of SHOW CREATE TABLE if there is an
AUTO_INCREMENT column, and NEXT_ID > 1 (the default). We must not print
the clause for engines that do not support this as it would break the
import of dumps, but as of this writing, the test for whether
AUTO_INCREMENT columns are allowed and wether AUTO_INCREMENT=...
is supported is identical, !(file->table_flags() & HA_NO_AUTO_INCREMENT))
Because of that, we do not explicitly test for the feature,
but may extrapolate its existence from that of an AUTO_INCREMENT column.
mysql-test/r/func_time.result:
Fix for bug #16546: DATETIME+0 not always coerced the same way
- test case
mysql-test/t/func_time.test:
Fix for bug #16546: DATETIME+0 not always coerced the same way
- test case
sql/item_timefunc.cc:
Fix for bug #16546: DATETIME+0 not always coerced the same way
- set decimals to DATETIME_DEC
sql/item_timefunc.h:
Fix for bug #16546: DATETIME+0 not always coerced the same way
- set decimals to DATETIME_DEC
Now test for NULLness the pointers returned from objects created from the
default value. Pushing patch on behalf of cmiller.
mysql-test/r/null.result:
Add test case
mysql-test/t/null.test:
Add test case
sql/sql_table.cc:
No longer blindly dereference pointer of the string representation of the
values, where "NULL" is NUL. Raise INVALID DEFAULT error messages where
appropriate.
Note that the -O1 optimization flag made debugging this extremely tricky, with
misleading results, and that removing it from the Makefile during debugging can
be invaluable.
In the code that converts IN predicates to EXISTS predicates it is changing
the select list elements to constant 1. Example :
SELECT ... FROM ... WHERE a IN (SELECT c FROM ...)
is transformed to :
SELECT ... FROM ... WHERE EXISTS (SELECT 1 FROM ... HAVING a = c)
However there can be no FROM clause in the IN subquery and it may not be
a simple select : SELECT ... FROM ... WHERE a IN (SELECT f(..) AS
c UNION SELECT ...) This query is transformed to : SELECT ... FROM ...
WHERE EXISTS (SELECT 1 FROM (SELECT f(..) AS c UNION SELECT ...)
x HAVING a = c) In the above query c in the HAVING clause is made to be
an Item_null_helper (a subclass of Item_ref) pointing to the real
Item_field (which is not referenced anywhere else in the query anymore).
This is done because Item_ref_null_helper collects information whether
there are NULL values in the result. This is OK for directly executed
statements, because the Item_field pointed by the Item_null_helper is
already fixed when the transformation is done. But when executed as
a prepared statement all the Item instances are "un-fixed" before the
recompilation of the prepared statement. So when the Item_null_helper
gets fixed it discovers that the Item_field it points to is not fixed
and issues an error. The remedy is to keep the original select list
references when there are no tables in the FROM clause. So the above
becomes : SELECT ... FROM ... WHERE EXISTS (SELECT c FROM (SELECT f(..)
AS c UNION SELECT ...) x HAVING a = c) In this way c is referenced
directly in the select list as well as by reference in the HAVING
clause. So it gets correctly fixed even with prepared statements. And
since the Item_null_helper subclass of Item_ref_null_helper is not used
anywhere else it's taken out.
mysql-test/r/ps_11bugs.result:
Test case for the bug
mysql-test/r/subselect.result:
Explain updated because of the tranformation
mysql-test/t/ps_11bugs.test:
Testcase for the bug
sql/item.cc:
Taking out Item_null_helper as it's no longer needed
sql/item.h:
Taking out Item_null_helper as it's no longer needed
sql/item_subselect.cc:
The described change to the IN->EXISTS transformation
Use files innodb_mysql.[test|result] instead.
mysql-test/t/innodb.test:
This file is to be used by Innobase only.
mysql-test/r/innodb_mysql.result:
New BitKeeper file ``mysql-test/r/innodb_mysql.result''
Use this file instead of innodb.result.
mysql-test/t/innodb_mysql.test:
New BitKeeper file ``mysql-test/t/innodb_mysql.test''
Use this file instead of innodb.test.
mysql-test/r/func_time.result:
Fix for bug #18501: Server crashes with monthname().
- test case
mysql-test/t/func_time.test:
Fix for bug #18501: Server crashes with monthname().
- test case
sql/item_timefunc.cc:
Fix for bug #18501: Server crashes with monthname().
- check null_value as well.
Update User_level_lock::thread_id on acquiring an existing lock,
and reset it on lock release.
mysql-test/r/func_misc.result:
Add result for bug#16501.
mysql-test/t/func_misc.test:
Add test case for bug#16501.
sql/item_func.cc:
Update User_level_lock::thread_id on acquiring an existing lock,
and reset it on lock release (for safety).
Backporting a changeset made for 5.0. Comments from there:
The fix refines the algorithm of generating DROPs for binlog.
Temp tables with common pseudo_thread_id are clustered into one query.
Consequently one replication event per pseudo_thread_id is generated.
mysql-test/r/rpl_temporary.result:
results changed
mysql-test/t/rpl_temporary.test:
test to generate problematic drop in binlog to feed it to restarting slave
to see no stop.
sql/sql_base.cc:
change in drop temprorary tables alg in close_temporary_tables.
The bug caused wrong result sets for union constructs of the form
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
For such queries order lists were concatenated and limit clause was
completely neglected.
mysql-test/r/order_by.result:
Added a test case for bug #18767.
mysql-test/t/order_by.test:
Added a test case for bug #18767.
sql/sql_lex.h:
Fixed bug #18767.
Placed the code the created a fake SELECT_LEX into a separate function.
sql/sql_parse.cc:
Fixed bug #18767.
Placed the code the created a fake SELECT_LEX into a separate function.
sql/sql_select.cc:
Fixed bug #18767.
Changed the condition on which a SELECT is treated as part of a UNION.
The SELECT in
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2
now is handled in the same way as the first SELECT in a UNION
sequence.
sql/sql_union.cc:
Fixed bug #18767.
Changed the condition at which a SELECT is treated as part of a UNION.
The SELECT in
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2
now is handled in the same way as the first SELECT in a UNION
sequence.
sql/sql_yacc.yy:
Fixed bug #18767.
Changed the condition at which a SELECT is treated as part of a UNION.
The SELECT in
(SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2
now is handled in the same way as the first SELECT in a UNION
sequence. In the same way is handled the SELECT in
(SELECT ... LIMIT n) ORDER BY order list.
Yet if there is neither ORDER BY nor LIMIT in the single-select
union construct
(SELECT ...) ORDER BY order_list
then it is still handled as simple select with an order clause.
Fixing part2 of this problem: AND didn't work well
with utf8_czech_ci and utf8_lithianian_ci in some cases.
The problem was because when during condition optimization
field was replaced with a constant, the constant's collation
and collation derivation was used later for comparison instead
of the field collation and derivation, which led to non-equal
new condition in some cases.
This patch copies collation and derivation from the field being removed
to the new constant, which makes comparison work using the same collation
with the one which would be used if no condition optimization were done.
In other words:
where s1 < 'K' and s1 = 'Y';
was rewritten to:
where 'Y' < 'K' and s1 = 'Y';
Now it's rewritten to:
where 'Y' collate collation_of_s1 < 'K' and s1 = 'Y'
(using derivation of s1)
Note, the first problem of this bug (with latin1_german2_ci) was fixed
earlier in 5.0 tree, in a separate changeset.
mysql-test/r/ctype_utf8.result:
Adding test case
mysql-test/t/ctype_utf8.test:
Adding test case
sql/sql_select.cc:
Set proper collation of the new item
Corrected test case for the bug#14169 to make it pass in --ps-protocol mode.
mysql-test/r/func_gconcat.result:
Corrected test case for the bug#14169 to make it pass in --ps-protocol mode.
The bug caused a reported index corruption in the cases when
key_cache_block_size was not a multiple of myisam_block_size,
e.g. when key_cache_block_size=1536 while myisam_block_size=1024.
mysql-test/r/key_cache.result:
Added a test case for bug #19079.
mysql-test/t/key_cache.test:
Added a test case for bug #19079.
MySQL 4.1
and Bug#16920 rpl_deadlock_innodb fails in show slave status (reported for MySQL 5.1)
- backport of several fixes done in MySQL 5.0 to 4.1
- fix for new discovered instability (see comment on Bug#12429 + Bug#16920)
- reenabling of testcases
mysql-test/r/rpl_deadlock.result:
Updated results
mysql-test/r/rpl_relayrotate.result:
Updated results
mysql-test/t/disabled.def:
Reenabling of tests
mysql-test/t/rpl_deadlock.test:
- replace sleep with real_sleep (backport fix for Bug#15624 MySQL 5.0)
- egalized value for Slave_IO_Running
- line 105 (backport fix for Bug#12429 MySQL 5.0)
- line 85 (see comment in Bug#12429
+ Bug#16920 rpl_deadlock_innodb fails in show slave status)
- improve readability of show slave status output (--vertical_results)
mysql-test/t/rpl_relayrotate.test:
- Replace select ... with select max(a)
- add sync_with_master (backport fix done by Kristian in MySQL 5.0 because of timing
problems similar to Bug#15624)
mysql-test/t/rpl_until.test:
Add wait_for_slave_to_stop like in the current MySQL 5.0 version of this test.
I assume this makes the test results more predictable.
Conversion from int and real numbers to UCS2 didn't work fine:
CONVERT(100, CHAR(50) UNICODE)
CONVERT(103.9, CHAR(50) UNICODE)
The problem appeared because numbers have binary charset, so,
simple charset recast binary->ucs2 was performed
instead of real conversion.
Fixed to make numbers pretend to be non-binary.
mysql-test/r/ctype_ucs.result:
Adding test case
mysql-test/t/ctype_ucs.test:
Adding test case
sql/item_timefunc.cc:
Adding new member from_cs, to replace my_charset_bin
to a non-binary charset when converting from numbers to UCS2
sql/item_timefunc.h:
Adding new member from_cs, to replace my_charset_bin
to a non-binary charset when converting from numbers to UCS2
used
In a simple queries a result of the GROUP_CONCAT() function was always of
varchar type.
But if length of GROUP_CONCAT() result is greater than 512 chars and temporary
table is used during select then the result is converted to blob, due to
policy to not to store fields longer than 512 chars in tmp table as varchar
fields.
In order to provide consistent behaviour, result of GROUP_CONCAT() now
will always be converted to blob if it is longer than 512 chars.
Item_func_group_concat::field_type() is modified accordingly.
mysql-test/t/func_gconcat.test:
Added test case for bug#14169: type of group_concat() result changed to blob if tmp_table was used
mysql-test/r/func_gconcat.result:
Added test case for bug#14169: type of group_concat() result changed to blob if tmp_table was used
sql/unireg.h:
Added the CONVERT_IF_BIGGER_TO_BLOB constant
sql/sql_select.cc:
Fixed bug#14169: type of group_concat() result changed to blob if tmp_table was used
The unnamed constant 255 in the create_tmp_field() and create_tmp_field_from_item() functions now defined as the CONVERT_IF_BIGGER_TO_BLOB constant.
The create_tmp_field() function now converts the Item_sum string result to a blob field based on its char length.
sql/item_sum.h:
Fixed bug#14169: type of group_concat() result changed to blob if tmp_table was used
To the Item_func_group_concat calls added the member function field_type() which returns the BLOB or VAR_STRING type based on the items length.
sql/item_func.cc:
Fixed bug#14169: type of group_concat() result changed to blob if tmp_table was used
In the Item_func::tmp_table_field() function the unnamed constant 255 is changed to the CONVERT_IF_BIGGER_TO_BLOB constant.
The Item_func::tmp_table_field() function now measures the result length in chars rather than bytes when converting string result to a blob.
mysql-test/mysql-test-run.pl:
no ndbcluster needed here
mysql-test/mysql-test-run.sh:
no ndbcluster needed here
mysql-test/t/mysqltest.test:
this test shouldn't work with the embedded server
into mysql.com:/usr/home/ram/work/mysql-4.1
mysql-test/r/func_op.result:
Auto merged
sql/item_func.cc:
Auto merged
mysql-test/t/func_op.test:
SCCS merged
into mysql.com:/opt/local/work/mysql-4.1-16365
sql/mysql_priv.h:
Auto merged
sql/sql_class.h:
Auto merged
mysql-test/r/ps.result:
Manual merge
mysql-test/t/ps.test:
Manual merge
too many open statements". The patch adds a new global variable
@@max_prepared_stmt_count. This variable limits the total number
of prepared statements in the server. The default value of
@@max_prepared_stmt_count is 16382. 16382 small statements
(a select against 3 tables with GROUP, ORDER and LIMIT) consume
100MB of RAM. Once this limit has been reached, the server will
refuse to prepare a new statement and return ER_UNKNOWN_ERROR
(unfortunately, we can't add new errors to 4.1 without breaking 5.0). The limit is changeable after startup
and can accept any value from 0 to 1 million. In case
the new value of the limit is less than the current
statement count, no new statements can be added, while the old
still can be used. Additionally, the current count of prepared
statements is now available through a global read-only variable
@@prepared_stmt_count.
mysql-test/r/ps.result:
Test results fixed (a test case for Bug#16365)
mysql-test/t/ps.test:
A test case for Bug#16365 "Prepared Statements: DoS with too many
open statements". Also fix statement leaks in other tests.
sql/mysql_priv.h:
Add declarations for new global variables.
sql/mysqld.cc:
Add definitions of max_prepared_stmt_count, prepared_stmt_count.
sql/set_var.cc:
Implement support for @@prepared_stmt_count and
@@max_prepared_stmt_count. Currently these variables are queried
without acquiring LOCK_prepared_stmt_count due to limitations of
the set_var/sys_var class design. Updates are, however, protected
with a lock.
sql/set_var.h:
New declarations to add support for @@max_prepared_stmt_count.
Implement a new class, where the lock to be used when updating
a variable is a parameter.
sql/sql_class.cc:
Add accounting of the total number of prepared statements in the
server to the methods of Statement_map.
sql/sql_class.h:
Add accounting of the total number of prepared statements in the
server to the methods of Statement_map.
sql/sql_prepare.cc:
Statement_map::insert will now send a message in case of an
error.
gives wrong results". Implement previously missing
Item_row::cleanup. The bug is not repeatable in 5.0, probably
due to a coincidence: the problem is present in 5.0 as well.
mysql-test/r/ps.result:
Update the result file (Bug#16248)
mysql-test/t/ps.test:
Add a test case for Bug#16248 "WHERE (col1,col2) IN ((?,?)) gives
wrong results"
sql/item_row.cc:
Implement Item_row::cleanup(): we should reset used_tables_cache
before reexecution of a prepared statement. In case ROW
arguments contain a placeholder, used_tables_cache has PARAM_TABLE
bit set in statement prepare. As a result, when executing a statement,
the condition push down algorithm (make_cond_for_table) would think
that the WHERE clause belongs to the non-existent PARAM_TABLE and
wouldn't attach the WHERE clause to any of the real tables,
effectively optimizing the clause away.
sql/item_row.h:
Remove a never used member 'array_holder'. Add declaration for
Item_row::cleanup.
mysql-test/lib/mtr_process.pl:
Change from "mtr_error()" to "mtr_warning()" on some problems,
because "error" makes the whole suite abort which then makes "Do-compile" terminate,
so none of the following steps (including other etst suites) will be done.
mysql-test/mysql-test-run.sh:
Manual merge from 4.0 (which was a 5.1 backport):
"--with-ndbcluster" is already present,
"--with-ndbcluster-only" is really usable here.
mysql-test/mysql-test-run.sh:
Make "mysql-test-run.sh" accept (and ignore) the options "--with-ndbcluster"
and "--with-ndbcluster-only".
This is necessary because newer build tools will issue them, and the test
script should tolerate that.
Backport from 5.1 (Tomas Ulin, 2006-01-17)
Adding test case to cover queries which worked incorrectly earlier:
Bug#18321: Can't store EuroSign with latin1_german1_ci and latin1_general_ci
mysql-test/r/ctype_latin1.result:
Adding test case for Bug#18321: Can't store EuroSign with latin1_german1_ci and latin1_general_ci
mysql-test/t/ctype_latin1.test:
Adding test case for Bug#18321: Can't store EuroSign with latin1_german1_ci and latin1_general_ci
Let "make install" install mysql-test-run.pl
mysql.spec.sh:
Set $LDFLAGS from $MYSQL_BUILD_LDFLAGS (bug#16662)
support-files/mysql.spec.sh:
Set $LDFLAGS from $MYSQL_BUILD_LDFLAGS (bug#16662)
mysql-test/Makefile.am:
Let "make install" install mysql-test-run.pl
Bug #17705 "FT Index corruption occurs with UTF8 data..."
(Actually, the bug had nothing to do with FT index but with general key compression)
myisam/mi_search.c:
Fix error in prefix compression of keys in MyISAM when key length changed from 254 -> 255
mysql-test/r/ctype_utf8.result:
Test of fix for key compression bug
mysql-test/t/ctype_utf8.test:
Test of fix for key compression bug
The GROUP_CONCAT uses its own temporary table. When ROLLUP is present
it creates the second copy of Item_func_group_concat. This copy receives the
same list of arguments that original group_concat does. When the copy is
set up the result_fields of functions from the argument list are reset to the
temporary table of this copy.
As a result of this action data from functions flow directly to the ROLLUP copy
and the original group_concat functions shows wrong result.
Since queries with COUNT(DISTINCT ...) use temporary tables to store
the results the COUNT function they are also affected by this bug.
The idea of the fix is to copy content of the result_field for the function
under GROUP_CONCAT/COUNT from the first temporary table to the second one,
rather than setting result_field to point to the second temporary table.
To achieve this goal force_copy_fields flag is added to Item_func_group_concat
and Item_sum_count_distinct classes. This flag is initialized to 0 and set to 1
into the make_unique() member function of both classes.
To the TMP_TABLE_PARAM structure is modified to include the similar flag as
well.
The create_tmp_table() function passes that flag to create_tmp_field().
When the flag is set the create_tmp_field() function will set result_field
as a source field and will not reset that result field to newly created
field for Item_func_result_field and its descendants. Due to this there
will be created copy func to copy data from old result_field to newly
created field.
mysql-test/t/func_gconcat.test:
Added test for bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
mysql-test/r/func_gconcat.result:
Added test for bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
sql/sql_table.cc:
Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
Added 0 as a last parameter to create_tmp_field() to force old behaviour.
sql/sql_select.cc:
Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
Added the flag 'make_copy_field' to create_tmp_field(), so that for Item_result_field descendants create_tmp_field() sets the item's result field as a source field and deny resetting that result field to a new value.
sql/sql_class.h:
Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
Added the flag 'force_copy_fields' to the structure TMP_TABLE_PARAM in order to make create_tmp_field() force the creation of 'copy_field' objects.
sql/mysql_priv.h:
Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
Added the bool parameter 'make_copy_field' to create_tmp_field().
sql/item_sum.cc:
Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
Added initialization of the force_copy_fields flag and passing it to create_tmp_table() through TMP_TBLE_PARAM in the Item_func_group_concat and Item_sum_count_distinct member functions.
sql/item_sum.h:
Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
Added the flag 'force_copy_fields' to the Item_func_group_concat and Item_sum_count_distinct classes.
disallow the use of comma in SET members
mysql-test/r/create.result:
Fix for bug#15316 SET value having comma not correctly handled
test case
mysql-test/t/create.test:
Fix for bug#15316 SET value having comma not correctly handled
test case
into mysql.com:/usr/home/bar/mysql-4.1.b15376
include/m_ctype.h:
Auto merged
strings/ctype-bin.c:
Auto merged
strings/ctype-euc_kr.c:
Auto merged
strings/ctype-gb2312.c:
Auto merged
strings/ctype-ucs2.c:
Auto merged
Fixed that LIKE worked case insensitively for latin2_czech_cs,
which was wrong for a case sensitive collation.
include/m_ctype.h:
Making my_wildcmp_bin public instead of static
strings/ctype-bin.c:
Making my_wildcmp_bin public instead of static
strings/ctype-czech.c:
Use my_wildcmp_bin instead of case insensitive my_wildcmp_8bit
mysql-test/include/have_latin2_ch.inc:
New BitKeeper file ``mysql-test/include/have_latin2_ch.inc''
mysql-test/r/ctype_latin2_ch.result:
New BitKeeper file ``mysql-test/r/ctype_latin2_ch.result''
mysql-test/r/have_latin2_ch.require:
New BitKeeper file ``mysql-test/r/have_latin2_ch.require''
mysql-test/t/ctype_latin2_ch.test:
New BitKeeper file ``mysql-test/t/ctype_latin2_ch.test''
table.cc:
Fixing to use system_charset_info instead of default_charset_info.
Crash happened because the "ctype" array is empty in UCS2,
and thus cannot be used with my_isspace().
The reason why UCS2 appeared in this context was because of
of default_charset_info variable incorrectly substituted to my_isspace().
As functions check_db_name(), check_table_name() and check_column_name()
always get values in utf8, system_charset_info must be used instead.
ctype_ucs2_def.test, ctype_ucs2_def-master.opt, ctype_ucs2_def.result:
new file
sql/table.cc:
Bug#18004 Connecting crashes server when default charset is UCS2
Use of default_charset_info was wrong.
Functions check_db_name, check_table_name and check_column_name
get values of system_charset_info character set (utf8).
mysql-test/lib/mtr_timer.pl:
Fix bug where ^C would trigger cleanup handler in both parent and
timeout child processes, causing duplicated messages and potential
conflicts.
For "count(*) while index_column = value" an index read
is done. It consists of an index scan and retrieval of
each key.
For efficiency reasons the index scan stores the key in
the special buffer 'lastkey2' once only. At the first
iteration it notes this fact with the flag
HA_STATE_RNEXT_SAME in 'info->update'.
For efficiency reasons, the key retrieval for blobs
does not allocate a new buffer, but uses 'lastkey2'...
Now I clear the HA_STATE_RNEXT_SAME flag whenever the
buffer has been polluted. In this case, the index scan
copies the key value again (and sets the flag again).
include/my_base.h:
Bug#14980 - COUNT(*) incorrect on MyISAM table with certain INDEX
Changed the comment for HA_STATE_RNEXT_SAME as a warning
for future uses.
myisam/mi_delete.c:
Bug#14980 - COUNT(*) incorrect on MyISAM table with certain INDEX
Removing the flag HA_STATE_RNEXT_SAME from info->update
if info->lastkey2 was reused for another purpose than
index scanning.
myisam/mi_key.c:
Bug#14980 - COUNT(*) incorrect on MyISAM table with certain INDEX
Removing the flag HA_STATE_RNEXT_SAME from info->update
if info->lastkey2 was reused for another purpose than
index scanning.
myisam/mi_rnext_same.c:
Bug#14980 - COUNT(*) incorrect on MyISAM table with certain INDEX
Removed trailing space and fixed a comment.
myisam/mi_unique.c:
Bug#14980 - COUNT(*) incorrect on MyISAM table with certain INDEX
Removing the flag HA_STATE_RNEXT_SAME from info->update
if info->lastkey2 was reused for another purpose than
index scanning.
myisam/mi_update.c:
Bug#14980 - COUNT(*) incorrect on MyISAM table with certain INDEX
Removing the flag HA_STATE_RNEXT_SAME from info->update
if info->lastkey2 was reused for another purpose than
index scanning.
myisam/mi_write.c:
Bug#14980 - COUNT(*) incorrect on MyISAM table with certain INDEX
Removing the flag HA_STATE_RNEXT_SAME from info->update
if info->lastkey2 was reused for another purpose than
index scanning.
mysql-test/r/myisam.result:
Bug#14980 - COUNT(*) incorrect on MyISAM table with certain INDEX
Added test result.
mysql-test/t/myisam.test:
Bug#14980 - COUNT(*) incorrect on MyISAM table with certain INDEX
Added test.
- Back porting of some changes in later releases
- Corrected valgrind support
- Removed work around for TZ needed in VisualStudio 6
- Don't restart master to add special settings from "<testcase>-master.opt",
if same settngs as running master, feature request in bug#12433
- With --reorder, keep tests with same *-master.opt content together,
to save even more master restarts
mysql-test/lib/mtr_misc.pl:
Added functions to compare lists of options
mysql-test/lib/mtr_cases.pl:
Removed special code for Windows as in VC6 we unset
TZ to avoid library bug
mysql-test/mysql-test-run.pl:
Handle pseudo option --timezone=<spec> that sets TZ
- Decrease "slave_open_temp_tables" during reopen of truncated table.
- Add test "rpl_trunc_temp"
sql/sql_delete.cc:
Decrease "slave_open_temp_tables" after temporary table has been closed, it will be
increased again when the temp table is reopened after it's been truncated.
mysql-test/r/rpl_trunc_temp.result:
New BitKeeper file ``mysql-test/r/rpl_trunc_temp.result''
mysql-test/t/rpl_trunc_temp.test:
New BitKeeper file ``mysql-test/t/rpl_trunc_temp.test''
Check if the host of table hash record exactly matches host from GRANT command
mysql-test/r/grant.result:
Fix for bug#14385 GRANT and mapping to correct user account problems
test case
mysql-test/t/grant.test:
Fix for bug#14385 GRANT and mapping to correct user account problems
test case
union.result, union.test:
Adding test case.
item.cc:
Allow safe character set conversion in UNION
- string constant to column's charset
- to unicode
Thus, UNION now works the same with CONCAT (and other string functions)
in respect of aggregating arguments with different character sets.
sql/item.cc:
Allow character set conversion in UNION
- string to column's charset
- to unicode
Bug#15949 union + illegal mix of collations (IMPLICIT + COERCIBLE)
mysql-test/t/union.test:
Adding test case.
mysql-test/r/union.result:
Adding test case.
mysql-test/mysql-test-run.pl:
Add a "--comment=<string>" option (backport from 5.1).
Its sole purpose is to get logged, so that test evaluation gets easier.
See "Do-compile" for how it is called, and "gen-build-status-page" for its effect.
mysql-test/mysql-test-run.sh:
Add a "--comment=<string>" option, to get it logged when the test is run.
The purpose is to allow a better analysis when generating the status page
("gen-build-status-page").
See "Do-compile" for how it is used.
Fix URLs.
README:
Fix URL.
mysqltest.result:
Update test result for real_sleep error message.
mysqltest.c:
Fix do_sleep() to print correct command name for real_sleep.
client/mysqltest.c:
Fix do_sleep() to print correct command name for real_sleep.
mysql-test/r/mysqltest.result:
Update test result for real_sleep error message.
mysql-test/README:
Fix URL.
mysql-test/mysql-test-run.sh:
Fix URLs.
fixed in 5.0).
A post-review fix (Bug#13134)
mysql-test/r/heap.result:
Remove 'delayed' to make the test deterministic.
mysql-test/r/ps.result:
Remove an unneeded drop table (test case for Bug#13134)
mysql-test/t/heap.test:
Remove 'delayed' to make the test deterministic.
mysql-test/t/ps.test:
A post-review fix (Bug#13134)
column is increasing when table is recreated with PS/SP":
make use of create_field::char_length more consistent in the code.
Reinit create_field::length from create_field::char_length
for every execution of a prepared statement (actually fixes the
bug).
mysql-test/r/ps.result:
Test results fixed (Bug#13134)
mysql-test/t/ps.test:
A test case for Bug#13134 "Length of VARCHAR() utf8 column is
increasing when table is recreated with PS/SP"
sql/field.cc:
Move initialization of create_field::char_length to the constructor
of create_field.
sql/field.h:
Rename chars_length to char_length (to be consistent with
how this term is used throughout the rest of the code).
sql/sql_parse.cc:
Initialize char_length in add_field_to_list. This function
effectively works as another create_field constructor.
sql/sql_table.cc:
Reinit length from char_length for every field in
mysql_prepare_table. This is not needed if we're executing
a statement for the first time, however, at subsequent executions
length contains the number of bytes, not characters (as it's expected
to).
Give space for second and third slave port
mysql-test/mysql-test-run.pl:
Give space for second and third slave port
Define shell variables for all ports, and
list these at startup
mysql-test/mysql-test-run.sh:
Give space for second and third slave port
errorneously abort reporting failure to kill child processes, where in
reality the problem was merely that the child had become a zombie because
of missing waitpid() call.
mysql-test/lib/mtr_process.pl:
Fix race (on some platforms) when killing processes.
Bug #17257 ndb, update fails for inner joins if tables do not have Primary Key
change: the allocated area by setValue may not be around for later, store hidden key in special member variable instead
mysql-test/r/ndb_basic.result:
Bug #17249 delete statement with join where clause fails when table do not have pk
Bug #17257 update fails for inner joins if tables do not have Primary Key
mysql-test/t/ndb_basic.test:
Bug #17249 delete statement with join where clause fails when table do not have pk
Bug #17257 update fails for inner joins if tables do not have Primary Key
sql/ha_ndbcluster.cc:
Bug #17249 delete statement with join where clause fails when table do not have pk
Bug #17257 update fails for inner joins if tables do not have Primary Key
change: the allocated area by setValue may not be around for later, store hidden key in special member variable instead
sql/ha_ndbcluster.h:
Bug #17249 delete statement with join where clause fails when table do not have pk
Bug #17257 update fails for inner joins if tables do not have Primary Key
change: the allocated area by setValue may not be around for later, store hidden key in special member variable instead
This changeset is assumed to stay in 4.1.
client/mysql.cc:
BUG#16217 forced to introduce a separate mysql client command.
Feature is backported from 5.0, precisely
ChangeSet 1.2034 06/02/09 16:23:09 aelkin@mysql.com
(under second review at the moment)
mysql-test/r/mysqlbinlog.result:
changed in 5.0
mysql-test/t/mysqlbinlog.test:
backported from 5.0. The last part of the test to mimic bug#16217
sql/log_event.cc:
Inserting exclaiming comment command for mysql client made differently than in 5.0.
Parsing still is cheap enough not to think to modify server code instead.
mysql-test/r/kill.result:
This result chenged because of the correspondent test change.
mysql-test/t/kill.test:
This test fixed for kill on Mac OS X (which do not send OK)
Bug #17158 load data infile of char values into table of char with no (PK) fails to load
Bug #17081 Doing "LOAD DATA INFILE" directly after delete can cause missing data
mysql-test/r/ndb_load.result:
New BitKeeper file ``mysql-test/r/ndb_load.result''
mysql-test/t/ndb_load.test:
New BitKeeper file ``mysql-test/t/ndb_load.test''
mysql-test/r/ndb_blob.result:
replace+tinyblob back-patch from 5.0
mysql-test/t/ndb_blob.test:
replace+tinyblob back-patch from 5.0
ndb/src/ndbapi/NdbBlob.cpp:
replace+tinyblob back-patch from 5.0
MATCH and FULLTEXT
Fixed that fulltext query using PS results in unexpected behaviour
when executed 2 or more times.
mysql-test/r/fulltext.result:
Testcase for BUG#14496.
mysql-test/t/fulltext.test:
Testcase for BUG#14496.
sql/item_func.h:
In Item_func_match::cleanup() always reset ft_handler to 0.
Bug#16780: Extend port range to make space for 5.1 NDBCLUSTER_PORT_SLAVE
mysql-test/mysql-test-run.sh:
Bug#16780: Extend port range to make space for 5.1 NDBCLUSTER_PORT_SLAVE
mysql-test/t/rpl_ignore_table-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_ignore_table-slave.opt''
mysql-test/t/rpl_ignore_table.test:
New BitKeeper file ``mysql-test/t/rpl_ignore_table.test''
sql/sql_parse.cc:
BUG#15699,16487 merge of the fix made in 5.0
mysql-test/r/rpl_multi_update4.result:
New BitKeeper file ``mysql-test/r/rpl_multi_update4.result''
mysql-test/t/rpl_multi_update4-slave.opt:
New BitKeeper file ``mysql-test/t/rpl_multi_update4-slave.opt''
mysql-test/t/rpl_multi_update4.test:
New BitKeeper file ``mysql-test/t/rpl_multi_update4.test''
mysql-test/r/rpl_ignore_table.result:
New BitKeeper file ``mysql-test/r/rpl_ignore_table.result''
mysql-test/r/update.result:
Testcase for BUG#15935
mysql-test/t/update.test:
Testcase for BUG#15935
sql/sql_update.cc:
BUG#15935:
- Do account for the fact that used_index!=MAX_KEY is also true for cases
when quick select is used, and use quick select then (and not full index scan).
- Also removed the redundant "used_index= MAX_KEY" statement
When setup_fields() function finds field named '*' it expands it to the list
of all table fields. It does so by checking that the first char of
field_name is '*', but it doesn't checks that the '* is the only char.
Due to this, when updating table with a field named like '*name', such field
is wrongly treated as '*' and expanded. This leads to making list of fields
to update being longer than list of the new values. Later, the fill_record()
function crashes by dereferencing null when there is left fields to update,
but no more values.
Added check in the setup_fields() function which ensures that the field
expanding will be done only when '*' is the only char in the field name.
mysql-test/t/update.test:
Added test case for bug#16510: Updating field named like '*name' caused server crash
mysql-test/r/update.result:
Added test case for bug#16510: Updating field named like '*name' caused server crash
sql/sql_base.cc:
Fixed bug #16510: Updating field named like '*name' caused server crash.
Added check in the setup_fields() function which ensures that the field
expanding will be done only when '*' is the only char in the field name.
into mysql.com:/home/mydev/mysql-4.1-bug5390
sql/table.h:
Auto merged
mysql-test/r/lock.result:
BUG#5390 - problems with merge tables
Manual merge from 4.0.
mysql-test/t/lock.test:
BUG#5390 - problems with merge tables
Manual merge from 4.0.
sql/lock.cc:
BUG#5390 - problems with merge tables
Manual merge from 4.0.
