into mysql.com:/home/mysql-5.0-10418
mysql-test/t/outfile.test:
Auto merged
sql/item_strfunc.cc:
Auto merged
mysql-test/r/func_str.result:
expect NULL rather than error if file given to load_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/t/func_str.test:
show that load_file() will return NULL rather than throw an error
if file doesn't exist
a worse execution plan than in 4.1 for some queries.
It happened due the fact that at some conditions the
optimizer always preferred range or full index scan access
methods to lookup access methods even when the latter were much
cheaper.
The problem was not observed in 4.1 for the reported query
because the WHERE condition was not of a form that could
cause the problem.
Equality propagation introduced on 5.0 added an extra
predicate and changed the WHERE condition. The new condition
provoked the optimizer to make a bad choice.
The problem was fixed by the patch for bug 17379.
mysql-test/r/select.result:
Added a test case for bug #18940.
The problem was fixed by the patch for bug 17379.
mysql-test/t/select.test:
Added a test case for bug #18940.
The problem was fixed by the patch for bug 17379.
Re-work best_access_path() and find_best() to reuse E(#rows(range access)) as
E(#rows(ref[_or_null](const) access) only when it is appropriate.
[This is the final cumulative patch]
mysql-test/r/select.result:
BUG#17379: Testcase
mysql-test/r/subselect.result:
BUG#17379: Updated test results
mysql-test/t/select.test:
BUG#17379: Testcase
sql/opt_range.cc:
BUG#17379: Wrong reuse of E(#rows(range)) as E(#rows(ref(const))):
Make range optimizer together with TABLE::quick_* also return TABLE::quick_n_ranges
sql/sql_select.cc:
BUG#17379: Wrong reuse of E(#rows(range)) as E(#rows(ref(const))):
Re-work best_access_path() to reuse E(#rows(range access)) as
E(#rows(ref[_or_null](const) access) only when it is appropriate.
sql/table.h:
BUG#17379: Wrong reuse of E(#rows(range)) as E(#rows(ref(const))):
Make range optimizer together with TABLE::quick_* also return TABLE::quick_n_ranges
into mysql.com:/usr/home/ram/work/mysql-5.0
sql/item_timefunc.cc:
Auto merged
mysql-test/r/func_time.result:
merging
mysql-test/t/func_time.test:
merging
Correct a bug (that I introduced, after using Oracle's database software for
too many years) where the length of the database-sent data is incorrectly
used to infer NULLness.
client/mysql.cc:
No longer use the length of the data to infer whether it is NULL or not.
mysql-test/r/mysql.result:
Add result and version marker, and correct previous result.
mysql-test/t/mysql.test:
Add test and version marker
"alter table from MyISAM to MERGE lost data without errors and warnings"
Add new handlerton flag which prevent user from altering table storage
engine to storage engines which would lose data. Both 'blackhole' and
'merge' are marked with the new flag.
Tests included.
mysql-test/r/blackhole.result:
test for bug#10952
mysql-test/r/merge.result:
test for bug#10952
mysql-test/t/blackhole.test:
test for bug#10952
mysql-test/t/merge.test:
test for bug#10952
sql/ha_blackhole.cc:
Bug#10952
shouldn't be able to alter a table into a blackhole
sql/ha_myisammrg.cc:
Bug#10952
shouldn't be able to alter a table into a merge
sql/handler.h:
Bug#10952
new handlerton flag
sql/sql_table.cc:
Bug#10952
If alter is changing engine, check if new engine allows creating table
via ALTER statement.
When converting DISTINCT to GROUP BY where the columns are from the covering
index and they are quoted twice in the SELECT list the optimizer is creating
improper processing sequence. This is because of the fact that the columns
of the covering index are not recognized as such and treated as non-index
columns.
Generally speaking duplicate columns can safely be removed from the GROUP
BY/DISTINCT list because this will not add or remove new rows in the
resulting set. Duplicates can be removed even if they are not consecutive
(as is the case for ORDER BY, where the duplicate columns can be removed
only if they are consecutive).
So we can safely transform "SELECT DISTINCT a,a FROM ... ORDER BY a" to
"SELECT a,a FROM ... GROUP BY a ORDER BY a" instead of
"SELECT a,a FROM .. GROUP BY a,a ORDER BY a". We can even transform
"SELECT DISTINCT a,b,a FROM ... ORDER BY a,b" to
"SELECT a,b,a FROM ... GROUP BY a,b ORDER BY a,b".
The fix to this bug consists of checking for duplicate columns in the SELECT
list when constructing the GROUP BY list in transforming DISTINCT to GROUP
BY and skipping the ones that are already in.
mysql-test/r/distinct.result:
test case for the bug without loose index scan
mysql-test/r/group_min_max.result:
test case for the bug
mysql-test/t/distinct.test:
test case for the bug without loose index scan
mysql-test/t/group_min_max.test:
test case for the bug
sql/sql_select.cc:
duplicates check and removal
into neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
client/mysqltest.c:
Auto merged
mysql-test/mysql-test-run.pl:
Auto merged
sql/mysql_priv.h:
Auto merged
save global server variables before fiddling with them and restore them later
BitKeeper/deleted/.del-variables-master.opt~8a6cb6459b54545:
Delete: mysql-test/t/variables-master.opt
mysql-test/r/variables.result:
save and restore globals
mysql-test/t/variables.test:
save and restore globals
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
into mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0-bug19136
sql/item_func.cc:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/r/rpl_user_variables.result:
manual merge use local
mysql-test/t/rpl_user_variables.test:
manual merge use version 5.0's "show binlog events from 98"
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.
into mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-merge
mysql-test/r/func_misc.result:
Manual merge of the fix for bug#16501.
mysql-test/t/func_misc.test:
Manual merge of the fix for bug#16501.
sql/item_func.cc:
Manual merge of the fix for bug#16501.
sql/sql_acl.cc:
For the fix of bug#16372, use local version, since the fix for 5.0 is
different, and will go in separate ChangeSet.
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.
mysql-test/r/ndb_condition_pushdown.result:
bug#17421, changes NDB API pushdown LIKE arg to plain char
mysql-test/t/ndb_condition_pushdown.test:
bug#17421, changes NDB API pushdown LIKE arg to plain char
ndb/include/ndbapi/NdbOperation.hpp:
bug#17421, changes NDB API pushdown LIKE arg to plain char
ndb/include/util/NdbSqlUtil.hpp:
bug#17421, changes NDB API pushdown LIKE arg to plain char
ndb/src/common/util/NdbSqlUtil.cpp:
bug#17421, changes NDB API pushdown LIKE arg to plain char
into ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0
mysql-test/r/date_formats.result:
Auto merged
mysql-test/t/date_formats.test:
Auto merged
sql/item_timefunc.cc:
Merged from 4.1
mysql-test-run now fails in case of warnings
mysql-test/lib/mtr_report.pl:
Fail if find warnings
mysql-test/mysql-test-run.sh:
Fail if find warnings
sql/sql_lex.cc:
Initalize st_lex properly
sql/sql_view.cc:
Fixed problem with unaligned memory (wrong free)
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"
- Move "chmod" part of information_schema test to separate file
mysql-test/r/information_schema.result:
Move "chmod" part of information_schema test to separate file
mysql-test/t/information_schema.test:
Move "chmod" part of information_schema test to separate file
mysql-test/r/information_schema_chmod.result:
Move "chmod" part of information_schema test to separate file
mysql-test/t/information_schema_chmod.test:
Move "chmod" part of information_schema test to separate file
into ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0
mysql-test/r/gis-rtree.result:
Auto merged
mysql-test/r/ansi.result:
Merged from 4.1
mysql-test/r/auto_increment.result:
Merged from 4.1
mysql-test/r/mysqldump.result:
Merged from 4.1
mysql-test/r/symlink.result:
Merged from 4.1
mysql-test/t/auto_increment.test:
Merged from 4.1
mysql-test/t/mysqldump.test:
Merged from 4.1
sql/set_var.cc:
Merged from 4.1
sql/sql_show.cc:
Merged from 4.1
