dropping/creating tables".
The bug could lead to a crash when multi-delete statements were
prepared and used with temporary tables.
The bug was caused by lack of clean-up of multi-delete tables before
re-execution of a prepared statement. In a statement like
DELETE t1 FROM t1, t2 WHERE ... the first table list (t1) is
moved to lex->auxilliary_table_list and excluded from lex->query_tables
or select_lex->tables. Thus it was unaccessible to reinit_stmt_before_use
and not cleaned up before re-execution of a prepared statement.
mysql-test/r/ps.result:
Updated test results (Bug#19399)
mysql-test/t/ps.test:
A test case for Bug#19399 "Stored Procedures 'Lost Connection' when
dropping/creating tables": test that multi-delete
tables are cleaned up properly before re-execution.
sql/sql_lex.cc:
Always initialize auxilliary_table_list when we initialize the lex:
this way we don't have to check that lex->sql_command equals to
SQLCOM_DELETE_MULTI whenever we need to access auxilliary_table_list.
In particular, in reinit_stmt_before_use we can simply check that
auxilliary_table_list is not NULL and clean it up if the check returns
a true value.
sql/sql_prepare.cc:
Move the one table clean-up functionality to a method of st_table_list.
Clean up auxiliary_table_list if it's not empty.
sql/table.cc:
Implement st_table_list::reinit_before_use().
sql/table.h:
Declare st_table_list::reinit_before_use().
The implementation of the method Item_func_reverse::val_str
for the REVERSE function modified the argument of the function.
This led to wrong results for expressions that contained
REVERSE(ref) if ref occurred somewhere else in the expressions.
mysql-test/r/func_str.result:
Added a test case for bug #18243.
mysql-test/t/func_str.test:
Added a test case for bug #18243.
sql/item_strfunc.cc:
Fixed bug #18243.
The implementation of the method Item_func_reverse::val_str
for the REVERSE function modified the argument of the function.
This led to wrong results for expressions that contained
REVERSE(ref) if ref occurred somewhere else in the expressions.
The implementation of Item_func_reverse::val_str has been changed
to make the argument intact.
sql/item_strfunc.h:
Fixed bug #18243.
Added tmp_value to the Item_func_reverse class to store
the result of the function. It erroneously replaced the
argument before this fix.
"temporary table with data directory option fails"
myisam should not use user-specified table name when creating
temporary tables and use generated connection specific real name.
Test included.
myisam/mi_create.c:
Bug#8706
When creating a temporary table with directory override, ensure that
the real filename is using the hidden temporary name otherwise
multiple clients cannot have same named temporary tables without
conflict.
mysql-test/r/myisam.result:
Bug#8706
Test for bug
mysql-test/t/myisam.test:
Bug#8706
Test for bug
(implemented by by Josh Chamas)
libmysqld/Makefile.am:
Adding new source file
mysql-test/r/date_formats.result:
Adding test case
mysql-test/t/date_formats.test:
Adding test case
sql/Makefile.am:
Adding new source file
BitKeeper/etc/ignore:
Added libmysqld/sql_locale.cc to the ignore list
sql/item_timefunc.cc:
Using current locale data, instead of hard coded English names.
sql/mysql_priv.h:
Adding new type MY_LOCALE, and declaring new global variables.
sql/set_var.cc:
Adding "lc_time_names" system variable.
sql/set_var.h:
Adding "lc_time_names" system variable.
sql/sql_cache.cc:
Adding lc_time_names as a query cache flag.
sql/sql_class.cc:
Setting default locale to en_US
sql/sql_class.h:
Adding locale variable into system_variables.
sql/sql_locale.cc:
Adding new file with locale data for various languages
running)
I decided to make ps_1general test independent from actual number of
threads running
mysql-test/r/ps_1general.result:
result fixed
mysql-test/t/ps_1general.test:
as i think we don't really care about the number of threads running
i just replace the number with '#'
mysql-test/r/key.result:
Fixed result after removing wrong bug fix
mysql-test/t/key.test:
Added SHOW CREATE TABLE, which is the proper way to check for table definitions
sql/table.cc:
Reverted wrong bug fix.
The intention with the original code was to show that MySQL treats the first
given unique key as a primary key. Clients can use the marked primary key as a
real primary key to validate row changes in case of conflicting updates. The
ODBC driver (and other drivers) may also use this fact to optimize/check
updates and handle conflicts. The marked key also shows what some engines, like InnoDB or NDB,
will use as it's internal primary key.
For checking if someone has declared a true PRIMARY KEY, one should use 'SHOW CREATE TABLE'
- Added comments.
- Make SEL_ARG::clone() set SEL_ARG::elements in the created copy.
mysql-test/r/range.result:
BUG#16168: Testcase
mysql-test/t/range.test:
BUG#16168: Testcase
client/mysql.cc:
Remove trailing spaces from help arguments in com_server_help.
Disregard trailing spaces from command in com_help.
mysql-test/r/mysql_client.result:
Test trailing spaces on the help command.
mysql-test/t/mysql_client.test:
Result trailing spaces on the help command.
CHECK TABLE could complain about a fully intact spatial index.
A wrong comparison operator was used for table checking.
The result was that it checked for non-matching spatial keys.
This succeeded if at least two different keys were present,
but failed if only the matching key was present.
I fixed the key comparison.
myisam/mi_check.c:
Bug#17877 - Corrupted spatial index
Fixed the comparison operator for checking a spatial index.
Using MBR_EQUAL | MBR_DATA to compare for equality and
include the data pointer in the comparison. The latter
finds the index entry that points to the current record.
This is necessary for non-unique indexes.
The old operator, SEARCH_SAME, is unknown to the rtree
search functions and handled like MBR_DISJOINT.
myisam/mi_key.c:
Bug#17877 - Corrupted spatial index
Added a missing DBUG_RETURN.
myisam/rt_index.c:
Bug#17877 - Corrupted spatial index
Included the data pointer in the copy of the search key.
This is necessary for searching the index entry that points
to a specific record if the search_flag contains MBR_DATA.
myisam/rt_mbr.c:
Bug#17877 - Corrupted spatial index
Extended the RT_CMP() macro with an assert for an
unexpected comparison operator.
mysql-test/r/gis-rtree.result:
Bug#17877 - Corrupted spatial index
The test result.
mysql-test/t/gis-rtree.test:
Bug#17877 - Corrupted spatial index
The test case.
mysql-test/r/grant2.result:
Added results for bug#16180
mysql-test/t/grant2.test:
Added test for bug# 16180
sql/set_var.cc:
Verify user has appropiate rights before setting the sql_log_off system variable.
Produce a warning if DATA/INDEX DIRECTORY is specified in
ALTER TABLE statement.
Ignoring of these options is documented in the symbolic links
section of the manual.
mysql-test/r/symlink.result:
Modified test result according to fix for BUG#1662.
sql/sql_parse.cc:
Produce a warning if DATA/INDEX DIRECTORY is specified in
ALTER TABLE statement.
mysql-test/r/func_sapdb.result:
test cases for date range edge cases added
mysql-test/r/func_time.result:
test cases for date range edge cases added
mysql-test/t/func_sapdb.test:
test cases for date range edge cases added
mysql-test/t/func_time.test:
test cases for date range edge cases added
'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''
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/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.
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
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
- 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
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.
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
