The problem was that when a QUICK_SELECT access method is chosen,
test_if_skip_sort_order() discovered that the index being used
by the quick select will not deliver tuples in sorted order.
In this case test_if_skip_sort_order() tried to change the index
used by the quick select, but it didn't properly set the other
members of the quick select, and especially the range flags of
the ranges in QUICK_SELECT::ranges.
The fix re-invokes the function SQL_SELECT::test_quick_select
to correctly create a valid QUICK_SELECT object.
mysql-test/r/order_by.result:
Added test results.
mysql-test/t/order_by.test:
Added test for BUG#7331.
sql/sql_select.cc:
Fix for BUG#7331.
report test mode if case of failure (default/ps-protocol/embedded)
mysql-test/mysql-test-run.sh:
report test mode if case of failure (default/ps-protocol/embedded)
_stricmp was replaved on sting_compare_func
added breakes for windows
mysql-test/mysql_test_run_new.c:
_stricmp was replaved on sting_compare_func
added breakes for windows
Link mysql_test_run_new as console application
my_manage.c:
The type intptr_t isn't defined for VC 6.0
Changed return type for CreateProcess() to bool
mysql_test_run_new.c:
The type intptr_t isn't defined for VC 6.0
mysqltest.dsp:
Added regex to additional build types for mysqltest
mysqldump.dsp:
Added mysys.lib for linking mysqldump
VC++Files/client/mysqldump.dsp:
Added mysys.lib for linking mysqldump
VC++Files/client/mysqltest.dsp:
Added regex to additional build types for mysqltest
mysql-test/mysql_test_run_new.c:
The type intptr_t isn't defined for VC 6.0
mysql-test/my_manage.c:
The type intptr_t isn't defined for VC 6.0
Changed return type for CreateProcess() to bool
VC++Files/mysql-test/mysql_test_run_new.dsp:
Link mysql_test_run_new as console application
Added missing stop_reap_all() if returns early from function
mysql-test-run.pl:
Improved output from --script-debug
Initial Cygwin support
Improved mysqld process termination
mysql-test/mysql-test-run.pl:
Improved output from --script-debug
Initial Cygwin support
Improved mysqld process termination
mysql-test/lib/mtr_process.pl:
Added missing stop_reap_all() if returns early from function
Added initial support for multiple test suites
Added usage information, i.e. --help
mysql-test/mysql-test-run.pl:
Added initial support for multiple test suites
Added usage information, i.e. --help
mysql-test/r/grant2.result:
new test case
mysql-test/r/variables.result:
don't fail w/o innodb
mysql-test/t/grant2.test:
new test case
mysql-test/t/multi_update.test:
don't fail w/o innodb
mysql-test/t/variables.test:
don't fail w/o innodb
sql/sql_acl.cc:
cleanup
This allows use to use INSERT IGNORE ... ON DUPLICATE ...
mysql-test/r/drop.result:
safety fix
mysql-test/t/drop.test:
safety fix
mysql-test/t/multi_update.test:
ensure we cover all possible errors
sql/log_event.cc:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/log_event.h:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/mysql_priv.h:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_class.h:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_delete.cc:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_insert.cc:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_lex.cc:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_lex.h:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_load.cc:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_parse.cc:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_repl.cc:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_repl.h:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_select.cc:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_table.cc:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_union.cc:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_update.cc:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
sql/sql_yacc.yy:
Remove DUP_IGNORE from enum_duplicates and instead use a separate ignore flag
correctly even with zero month and day" and bug #7515 "from_unixtime(0)
now returns NULL instead of the Epoch" into 4.1 tree.
mysql-test/r/ps_2myisam.result:
Updated test result after merging fix for bug #7297 "Two digit year should
be interpreted correctly even with zero month and day" into 4.1
mysql-test/r/ps_3innodb.result:
Updated test result after merging fix for bug #7297 "Two digit year should
be interpreted correctly even with zero month and day" into 4.1
mysql-test/r/ps_4heap.result:
Updated test result after merging fix for bug #7297 "Two digit year should
be interpreted correctly even with zero month and day" into 4.1
mysql-test/r/ps_5merge.result:
Updated test result after merging fix for bug #7297 "Two digit year should
be interpreted correctly even with zero month and day" into 4.1
mysql-test/r/ps_6bdb.result:
Updated test result after merging fix for bug #7297 "Two digit year should
be interpreted correctly even with zero month and day" into 4.1
mysql-test/r/ps_7ndb.result:
Updated test result after merging fix for bug #7297 "Two digit year should
be interpreted correctly even with zero month and day" into 4.1
sql-common/my_time.c:
Merged fix for bug #7297 "Two digit year should be interpreted correctly
even with zero month and day" into 4.1
sql/item_timefunc.cc:
Small fix after merging patch solving bug #7515 "from_unixtime(0) now
returns NULL instead of the Epoch" into 4.1.
the Epoch". (With after review fixes).
mysql-test/r/func_time.result:
Added test for bug #7515 "from_unixtime(0) now returns NULL instead of
the Epoch".
mysql-test/t/func_time.test:
Added test for bug #7515 "from_unixtime(0) now returns NULL instead of
the Epoch".
sql/item_timefunc.cc:
Item_func_from_unixtime:
from_unixtime(0) should return Epoch instead of NULL.
sql/item_timefunc.h:
Item_func_from_unixtime:
- Removed unused method definition.
- fix_length_and_dec() should set maybe_null to true since now
from_unixtime() can return NULL even in case when none of its
arguments is NULL.
Perl version of mysql-test-run
new file
mysql-test/lib/init_db.sql:
Perl version of mysql-test-run
mysql-test/lib/mtr_gcov.pl:
Perl version of mysql-test-run
mysql-test/lib/mtr_gprof.pl:
Perl version of mysql-test-run
mysql-test/lib/mtr_io.pl:
Perl version of mysql-test-run
mysql-test/lib/mtr_match.pl:
Perl version of mysql-test-run
mysql-test/lib/mtr_misc.pl:
Perl version of mysql-test-run
mysql-test/lib/mtr_process.pl:
Perl version of mysql-test-run
mysql-test/lib/mtr_report.pl:
Perl version of mysql-test-run
mysql-test/mysql-test-run.pl:
Perl version of mysql-test-run
When we cast datetime value to DATE (TIME) type we should throw away its
time (date) part. This was not done properly if CAST() function was used
in datetime expressions.
mysql-test/r/cast.result:
Added test for bug #6914 "Problems using time()/date() output in
expressions".
mysql-test/t/cast.test:
Added test for bug #6914 "Problems using time()/date() output in
expressions".
sql/item_timefunc.cc:
Item_time_typecast::get_time()/Item_date_typecast::get_date():
When we cast datetime value to DATE we should throw away its time part.
When we cast such value to TIME type we should throw away its date part.
The fix checks if the trim string argument is NULL. If so, the standard
mandates that the function result must be also NULL.
mysql-test/r/func_str.result:
added test result
mysql-test/t/func_str.test:
Added test for NULL arguments.
sql/item_strfunc.cc:
Test if the trim argument is NULL.
- Added a hash to keep track of database-table pairs.
- Specified database-table tables do not get dumped
client/client_priv.h:
WL#2319 V2: Exclude tables from dump
client/mysqldump.c:
WL#2319 V2: Exclude tables from dump
mysql-test/r/mysqldump.result:
WL#2319 V2: Exclude tables from dump
mysql-test/t/mysqldump.test:
WL#2319 V2: Exclude tables from dump
mysql-test/r/merge.result:
Added test result for BUG#7377.
mysql-test/t/merge.test:
Added test for BUG#7377.
sql/ha_myisammrg.cc:
Added implementation for handler::index_type.
sql/ha_myisammrg.h:
Added implementation for handler::index_type.
Added a couple of new test cases for bug #7351.
mysql-test/t/subselect.test:
Added a couple of new test cases for bug #7351.
mysql-test/r/subselect.result:
Added a couple of new test cases for bug #7351.
Added test cases for bug #7351.
item_cmpfunc.cc:
Fixed bug #7351: incorrect result for a query with a
subquery returning empty set.
If in the predicate v IN (SELECT a FROM t WHERE cond)
v is null, then the result of the predicate is either
INKNOWN or FALSE. It is FALSE if the subquery returns
an empty set.
item_subselect.cc:
Fixed bug #7351: incorrect result for a query with a
subquery returning empty set.
The problem was due to not a quite legal transformation
for 'IN' subqueries. A subquery containing a predicate
of the form
v IN (SELECT a FROM t WHERE cond)
was transformed into
EXISTS(SELECT a FROM t WHERE cond AND (a=v OR a IS NULL)).
Yet, this transformation is valid only if v is not null.
If v is null, then, in the case when
(SELECT a FROM t WHERE cond) returns an empty set the value
of the predicate is FALSE, otherwise the result of the
predicate is INKNOWN.
The fix resolves this problem by changing the result
of the transformation to
EXISTS(SELECT a FROM t WHERE cond AND (v IS NULL OR (a=v OR a IS NULL)))
in the case when v is nullable.
The new transformation prevents applying the lookup
optimization for IN subqueries. To make it still
applicable we have to introduce guarded access methods.
sql/item_subselect.cc:
Fixed bug #7351: incorrect result for a query with a
subquery returning empty set.
The problem was due to not a quite legal transformation
for 'IN' subqueries. A subquery containing a predicate
of the form
v IN (SELECT a FROM t WHERE cond)
was transformed into
EXISTS(SELECT a FROM t WHERE cond AND (a=v OR a IS NULL)).
Yet, this transformation is valid only if v is not null.
If v is null, then, in the case when
(SELECT a FROM t WHERE cond) returns an empty set the value
of the predicate is FALSE, otherwise the result of the
predicate is INKNOWN.
The fix resolves this problem by changing the result
of the transformation to
EXISTS(SELECT a FROM t WHERE cond AND (v IS NULL OR (a=v OR a IS NULL)))
in the case when v is nullable.
The new transformation prevents applying the lookup
optimization for IN subqueries. To make it still
applicable we have to introduce guarded access methods.
sql/item_cmpfunc.cc:
Fixed bug #7351: incorrect result for a query with a
subquery returning empty set.
If in the predicate v IN (SELECT a FROM t WHERE cond)
v is null, then the result of the predicate is either
INKNOWN or FALSE. It is FALSE if the subquery returns
an empty set.
mysql-test/t/subselect.test:
Added test cases for bug #7351.
mysql-test/r/subselect.result:
Added test cases for bug #7351.
sql/item_strfunc.cc:
Auto merged
mysql-test/r/func_str.result:
merged test results for QUOTE() buf fix
mysql-test/t/func_str.test:
merged test for QUOTE() buf fix
mysql-test/r/func_str.result:
result for test case for a bug in QUOTE() (Bug #7495)
mysql-test/t/func_str.test:
test case for a bug in QUOTE() (Bug #7495)
sql/item_strfunc.cc:
a better fix for a QUOTE() bug (Bug #7495)
