Added a test case for bug #10124.
sql_select.h, item_subselect.cc, sql_select.cc:
Fixed bug #10124.
The copy method of the store_key classes can return
STORE_KEY_OK=0, STORE_KEY_FATAL=1, STORE_KEY_CONV=2 now.
field.cc:
Fixed bug #10124.
When ussuing a warning the store methods return 2 instead of 1 now.
sql/field.cc:
Fixed bug #10124.
When ussuing a warning the store methods return 2 instead of 1 now.
sql/sql_select.cc:
Fixed bug #10124.
The copy method of the store_key classes can return
STORE_KEY_OK=0, STORE_KEY_FATAL=1, STORE_KEY_CONV=2 now.
sql/item_subselect.cc:
Fixed bug #10124.
The copy method of the store_key classes can return
STORE_KEY_OK=0, STORE_KEY_FATAL=1, STORE_KEY_CONV=2 now.
sql/sql_select.h:
Fixed bug #10124.
The copy method of the store_key classes can return
STORE_KEY_OK=0, STORE_KEY_FATAL=1, STORE_KEY_CONV=2 now.
mysql-test/t/func_str.test:
Added a test case for bug #10124.
mysql-test/r/func_str.result:
Added a test case for bug #10124.
The source of the problem is in Field_longlong::cmp. If 'this' is
an unsigned number, the method casts both the current value, and
the constant that we compare with to an unsigned number. As a
result if the constant we compare with is a negative number, it
wraps to some unsigned number, and the comparison is incorrect.
When the optimizer chooses the "range" access method, this problem
causes handler::read_range_next to reject the current key when the
upper bound key is a negative number because handler::compare_key
incorrectly considers the positive and negative keys to be equal.
The current patch does not correct the source of the problem in
Field_longlong::cmp because it is not easy to propagate sign
information about the constant at query execution time. Instead
the patch changes the range optimizer so that it never compares
unsiged fields with negative constants. As an added benefit,
queries that do such comparisons will execute faster because
the range optimizer replaces conditions like:
(a) (unsigned_int [< | <=] negative_constant) == FALSE
(b) (unsigned_int [> | >=] negative_constant) == TRUE
with the corresponding constants.
In some cases this may even result in constant time execution.
mysql-test/r/range.result:
- Added test for BUG#11185
- Added missing test from 4.1. This test also tests the fix for BUG#11185.
mysql-test/t/range.test:
- Added test for BUG#11185
- Added missing test from 4.1. This test also tests the fix for BUG#11185.
sql/opt_range.cc:
Added a new optimization to the range optimizer where we detect that
an UNSIGNED field is compared with a negative constant. Depending on
the comparison operator, we know directly that the result of the
comparison is either TRUE or FALSE for all input values, and we need
not check each value.
This optimization is also necessary so that the index range access
method produces correct results when comparing unsigned fields with
negative constants.
Fixed buf #11487.
Added a call of QUICK_RANGE_SELECT::init to the
QUICK_RANGE_SELECT::reset method. Without it the second
evaluation of a subquery employing the range access failed.
subselect.result, subselect.test:
Added a test case for bug #11487.
mysql-test/t/subselect.test:
Added a test case for bug #11487.
mysql-test/r/subselect.result:
Added a test case for bug #11487.
sql/opt_range.cc:
Fixed buf #11487.
Added a call of QUICK_RANGE_SELECT::init to the
QUICK_RANGE_SELECT::reset method. Without it the second
evaluation of a subquery employing the range access failed.
The source of the problem is in Field_longlong::cmp. If 'this' is
an unsigned number, the method casts both the current value, and
the constant that we compare with to an unsigned number. As a
result if the constant we compare with is a negative number, it
wraps to some unsigned number, and the comparison is incorrect.
When the optimizer chooses the "range" access method, this problem
causes handler::read_range_next to reject the current key when the
upper bound key is a negative number because handler::compare_key
incorrectly considers the positive and negative keys to be equal.
The current patch does not correct the source of the problem in
Field_longlong::cmp because it is not easy to propagate sign
information about the constant at query execution time. Instead
the patch changes the range optimizer so that it never compares
unsiged fields with negative constants. As an added benefit,
queries that do such comparisons will execute faster because
the range optimizer replaces conditions like:
(a) (unsigned_int [< | <=] negative_constant) == FALSE
(b) (unsigned_int [> | >=] negative_constant) == TRUE
with the corresponding constants.
In some cases this may even result in constant time execution.
mysql-test/r/range.result:
- Changed incorrect result of an old test
- Added new results for BUG#11185
mysql-test/t/range.test:
- Added new tests for BUG#11185
- Deleted an old comment because now the problem is fixed
sql/opt_range.cc:
Added a new optimization to the range optimizer where we detect that
an UNSIGNED field is compared with a negative constant. Depending on
the comparison operator, we know directly that the result of the
comparison is either TRUE or FALSE for all input values, and we need
not check each value.
This optimization is also necessary so that the index range access
method produces correct results when comparing unsigned fields with
negative constants.
mysql-test/r/func_math.result:
Add new results
mysql-test/t/func_math.test:
Add new regression test
sql/item_func.cc:
Don't set result of abs() to unsigned. Result should still be
a signed value, even if always positive.
be the same. (Bug #11203)
mysql-test/r/loaddata.result:
Update results
mysql-test/t/loaddata.test:
Add new test
sql/sql_load.cc:
Handle having escape_char and enclosed_char the same when loading
data.
mysql-test/std_data/loaddata5.dat:
New BitKeeper file ``mysql-test/std_data/loaddata5.dat''
mysql-test/r/key.result:
Add new results
mysql-test/t/key.test:
Add new regression test
sql/table.cc:
Use keyinfo->key_parts to determine if key is part of a
multiple-field key or is unique.
client/mysqldump.c:
Fix progname of mysqldump
mysql-test/r/mysqldump.result:
Update test results
mysql-test/t/mysqldump.test:
Update tests, no need for results
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
client/mysqldump.c:
Auto merged
mysql-test/r/mysqldump.result:
Auto merged
mysql-test/t/mysqldump.test:
Auto merged
Correct test results now when error message output is predictable.
client/mysqldump.c:
Set mysqldump as progname instead of totally long and strange path provided by libtool.
mysql-test/r/mysqldump.result:
Update test results
mysql-test/t/mysqldump.test:
Update test result, removed --replace now ehn test output is predictable.
- Check the Dflag variable inside of function dump_table to see if data should be
dumped or not.
- Add test for --xml and --no-data as well
Reapplying patch!
client/mysqldump.c:
Move the check of --no-data flag and "number of fields" inside of the dump_table
function.
mysql-test/r/mysqldump.result:
Update test results add ouput for --xml and --no-data
mysql-test/t/mysqldump.test:
Add tests for XML and --no-data as well.
client/mysqltest.c:
Auto merged
mysql-test/mysql-test-run.sh:
Auto merged
mysql-test/t/ndb_autodiscover.test:
Auto merged
sql/ha_ndbcluster.h:
Auto merged
sql/item_strfunc.cc:
Auto merged
client/mysqldump.c:
Merge from 4.1 to 5.0
mysql-test/r/ndb_autodiscover.result:
Merge
ndb/test/ndbapi/create_tab.cpp:
Merge
sql/ha_ndbcluster.cc:
Merge
sql/handler.cc:
Merge
sql/handler.h:
Merge
sql/sql_base.cc:
Merge
sql/sql_table.cc:
Merge
Remove changes made by bug fix#8147. They strips list of insert_table_list to
only insert table, which results in error reported in bug #9728.
Added flag to Item to resolve ambigous fields reported in bug #8147.
sql/item.h:
Fix bug#9728 decreased functionality in "on duplicate key update".
sql/item.cc:
Fix bug#9728 decreased functionality in "on duplicate key update"
sql/sql_parse.cc:
Fix bug#9728 decreased functionality in "on duplicate key update"
sql/sql_base.cc:
Fix bug#9728 decreased functionality in "on duplicate key update".
sql/sql_yacc.yy:
Fix bug#9728 decreased functionality in "on duplicate key update"
mysql-test/t/insert_select.test:
Test case for bug#9728 Decreased functionality in "on duplicate key update".
mysql-test/r/insert_select.result:
Test case for bug#9728 Decreased functionality in "on duplicate key update".
into moonbone.local:/work/mysql-5.0-bug-11298
sql/item.cc:
Auto merged
sql/item.h:
Auto merged
mysql-test/r/view.result:
SCCS merged
mysql-test/t/view.test:
SCCS merged
when using ORDER BY
Insert were inserting data from last record fetched instead of inserting from
temporary table.
Make Item_ref to save data from result_field if it's available rather then
from *ref on save_in_field() call.
sql/item.h:
Fix bug#11298 insert into select from VIEW produces incorrect result when using ORDER BY
sql/item.cc:
Fix bug#11298 insert into select from VIEW produces incorrect result when using ORDER BY
mysql-test/r/view.result:
Test case for bug#11298 insert into select from VIEW produces incorrect result when using ORDER BY
mysql-test/t/view.test:
Test case for bug#11298 insert into select from VIEW produces incorrect result when using ORDER BY
mysql-test/r/sp.result:
test commented until bug#11394 fix
test for bug#10136
mysql-test/t/sp.test:
test commented until bug#11394 fix
bug10136
sql/sp_head.cc:
fixed items cleunup for SP
mysql-test/r/rpl_multi_update3.result:
Changes from code review
mysql-test/t/rpl_multi_update3.test:
Changes from code review
sql/sql_parse.cc:
Changes from code review
Temporary field wasn't restored to default values after ON DUPLICATE KEY
UPDATE event, which results in wrong data being inserted in new record.
sql/sql_insert.cc:
Fix bug #10886 - INSERT ... SELECT ... ON DUPLICATE KEY UPDATE produces bad results
mysql-test/t/insert_select.test:
Test case for bug #10886 - INSERT ... SELECT ... ON DUPLICATE KEY
UPDATE produces bad results
mysql-test/r/insert_select.result:
Test case for bug #10886 - INSERT ... SELECT ... ON DUPLICATE KEY UPDATE
produces bad results
