Addendum to thr fix for bug 30000:
show procedure/function code defined only in debug builds
show_check.test:
Addendum to thr fix for bug 30000:
show procedure/function code defined only in debug builds
mysql-test/t/show_check.test:
Addendum to thr fix for bug 30000:
show procedure/function code defined only in debug builds
mysql-test/r/show_check.result:
Addendum to thr fix for bug 30000:
show procedure/function code defined only in debug builds
into mysql.com:/home/hf/work/29878/my51-29878
mysql-test/suite/rpl/r/rpl_session_var.result:
Auto merged
mysql-test/suite/rpl/t/rpl_session_var.test:
Auto merged
sql/item.cc:
Auto merged
sql/item.h:
Auto merged
sql/item_strfunc.h:
Auto merged
slow query log
Disable the SHOW commands to appear in the show query
log.
Update the commands type array.
mysql-test/r/show_check.result:
Bug #30000: test case
mysql-test/t/show_check.test:
Bug #30000: test case
sql/sql_parse.cc:
Bug #30000: skip SHOW commands from the
slow query log.
Item_func_user doesn't calculate anything in it's val_str() method,
just returns saved str_value.
Though Item::save_in_field method can destroy str_value, relying on
val_str() return. As a result we get the garbage stored in field.
We cannot use Item::save_in_field implementation for Item_func_user,
reimplement it in simpler way.
mysql-test/r/rpl_session_var.result:
Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
test result
mysql-test/t/rpl_session_var.test:
Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
test case
sql/item.cc:
Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
duplicating code moved to Item::save_str_in_field
sql/item.h:
Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
duplicating code moved to Item::save_str_in_field
sql/item_strfunc.h:
Bug #29878 Garbage data generation when executing SESSION_USER() on a slave.
Item_func_user::save_in_field implemented as simple storing str_value
- reset the logs before and after the test.
- cleanup from the previous tests : use the correct schema.
mysql-test/extra/rpl_tests/rpl_insert_delayed.test:
5.0-opt -> 5.1-opt merge of the test case for bug 29571.
mysql-test/suite/rpl/r/rpl_stm_insert_delayed.result:
5.0-opt -> 5.1-opt merge of the test case for bug 29571.
into gleb.loc:/home/uchum/work/bk/5.1-opt
sql/sql_insert.cc:
Auto merged
BitKeeper/deleted/.del-bdb.result:
Auto merged
BitKeeper/deleted/.del-ha_berkeley.cc:
Auto merged
BitKeeper/deleted/.del-rpl_insert_delayed.result:
Auto merged
mysql-test/extra/rpl_tests/rpl_insert_delayed.test:
Auto merged
sql/sql_select.cc:
Merge with 5.0-opt.
sql/table.cc:
Merge with 5.0-opt.
- make ha_berkeley::cmp_ref() take into account that auto-generated PKs
are stored in LSB-first order.
- Remove the temporary code that made the bugfix work for innodb only
mysql-test/r/bdb.result:
Adjust test-results.
sql/ha_berkeley.cc:
BUG#28591: make the fix work for BDB tables too:
- make ha_berkeley::cmp_ref() take into account that auto-generated PKs
are stored in LSB-first order.
sql/sql_select.cc:
BUG#28591: Remove "innodb only" clause as the fix now works for BDB too
sql/table.cc:
BUG#28591: Remove "innodb only" clause as the fix now works for BDB too
SHOW TABLE TYPES is a (to be deprecated) synonym for
SHOW STORAGE ENGINES.
Fixed to use the right schema table in addition to
issuing a warning.
mysql-test/r/show_check.result:
Bug #30036: test case
mysql-test/t/show_check.test:
Bug #30036: test case
sql/sql_yacc.yy:
Bug #30036: use the right schema table
the master but on the slave
MySQL can decide to "downgrade" a INSERT DELAYED statement
to normal insert in certain situations.
One such situation is when the slave is replaying a
replication feed.
However INSERT DELAYED is logged even if there're no updates
whereas the NORMAL INSERT is not logged in such cases.
Fixed by always logging a "downgraded" INSERT DELAYED: even
if there were no updates.
mysql-test/r/rpl_insert_delayed.result:
Bug #29571: test case
mysql-test/t/rpl_insert_delayed.test:
Bug #29571: test case
sql/sql_insert.cc:
Bug #29571: log INSERT DELAYED even if it was
"downgraded" to INSERT (and there were no updates)
into gleb.loc:/home/uchum/work/bk/5.1-opt
mysql-test/t/create.test:
Auto merged
sql/field.cc:
Auto merged
sql/sql_base.cc:
Auto merged
sql/table.cc:
Auto merged
mysql-test/r/create.result:
Merge with 5.0-opt.
into gleb.loc:/home/uchum/work/bk/5.1-opt
mysql-test/r/sp.result:
Auto merged
mysql-test/t/create.test:
Auto merged
sql/field.cc:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/table.cc:
Auto merged
mysql-test/r/create.result:
Merge with 5.1 (main).
into gleb.loc:/home/uchum/work/bk/5.0-opt
mysql-test/t/create.test:
Auto merged
sql/field.cc:
Auto merged
sql/sql_base.cc:
Auto merged
sql/table.cc:
Auto merged
mysql-test/r/create.result:
Merge with 5.0 (main).
into gleb.loc:/home/uchum/work/bk/5.1-opt
mysql-test/r/having.result:
Auto merged
mysql-test/t/create.test:
Auto merged
mysql-test/t/having.test:
Auto merged
sql/field.cc:
Auto merged
sql/sql_select.cc:
Auto merged
mysql-test/include/mix1.inc:
Merge with 5.0-opt.
mysql-test/r/create.result:
Merge with 5.0-opt.
mysql-test/r/innodb_mysql.result:
Merge with 5.0-opt.
mysql-test/r/type_enum.result:
Merge with 5.0-opt.
mysql-test/t/type_enum.test:
Merge with 5.0-opt.
sql/filesort.cc:
Merge with 5.0-opt.
sql/sql_base.cc:
Merge with 5.0-opt.
sql/table.cc:
Merge with 5.0-opt.
storage/innobase/handler/ha_innodb.cc:
Merge with 5.0-opt.
When the SQL_BIG_RESULT flag is specified SELECT should store items from the
select list in the filesort data and use them when sending to a client.
The get_addon_fields function is responsible for creating necessary structures
for that. But this function was allowed to do so only for SELECT and
INSERT .. SELECT queries. This makes the SQL_BIG_RESULT useless for
the CREATE .. SELECT queries.
Now the get_addon_fields allows storing select list items in the filesort
data for the CREATE .. SELECT queries.
mysql-test/t/create.test:
Added a test case for the bug#15130: CREATE .. SELECT was denied to use
advantages of the SQL_BIG_RESULT.
mysql-test/r/create.result:
Added a test case for the bug#15130: CREATE .. SELECT was denied to use
advantages of the SQL_BIG_RESULT.
sql/filesort.cc:
Bug#15130: CREATE .. SELECT was denied to use advantages of the SQL_BIG_RESULT.
Now the get_addon_fields allows storing select list items in the filesort
data for the CREATE .. SELECT queries.
Changed the default location of the log output to LOG_FILE,
for backward compatibility with MySQL 5.0
mysql-test/r/log_state.result:
Changed the default location of the log output to LOG_FILE,
for backward compatibility with MySQL 5.0
sql/set_var.cc:
Changed the default location of the log output to LOG_FILE,
for backward compatibility with MySQL 5.0
into magare.gmz:/home/kgeorge/mysql/autopush/B29644-5.0-opt
sql/ha_innodb.cc:
Auto merged
sql/sql_base.cc:
Auto merged
mysql-test/r/innodb_mysql.result:
5.0-opt merge
mysql-test/t/innodb_mysql.test:
5.0-opt merge
Limit the fix for bug 28591 to InnoDB only
sql/sql_select.cc:
Limit the fix for bug 28591 to InnoDB only
sql/table.cc:
Limit the fix for bug 28591 to InnoDB only
If a primary key is defined over column c of enum type then
the EXPLAIN command for a look-up query of the form
SELECT * FROM t WHERE c=0
said that the query was with an impossible where condition though the
query correctly returned non-empty result set when the table indeed
contained rows with error empty strings for column c.
This kind of misbehavior was due to a bug in the function
Field_enum::store(longlong,bool) that erroneously returned 1 if
the the value to be stored was equal to 0.
Note that the method
Field_enum::store(const char *from,uint length,CHARSET_INFO *cs)
correctly returned 0 if a value of the error empty string
was stored.
mysql-test/r/type_enum.result:
Added a test case for bug #29661.
mysql-test/t/type_enum.test:
Added a test case for bug #29661.
sql/field.cc:
Fixed bug #29611.
If a primary key was defined over column c of enum type then
the EXPLAIN command for a look-up query of the form
SELECT * FROM t WHERE c=0
said that the query was with an impossible where condition though the
query correctly returned non-empty result set when the table indeed
contained rows with error empty strings for column c.
This kind of misbehavior was due to a bug in the function
Field_enum::store(longlong,bool) that erroneously returned 1 if
the the value to be stored was equal to 0.
Note that the method
Field_enum::store(const char *from,uint length,CHARSET_INFO *cs)
correctly returned 0 if a value of the error empty string
was stored.
into magare.gmz:/home/kgeorge/mysql/autopush/B28951-5.0-opt
mysql-test/t/innodb_mysql.test:
Auto merged
sql/sql_select.cc:
Auto merged
sql/table.cc:
Auto merged
mysql-test/r/innodb_mysql.result:
merge of 5.0-opt
Additional test case fix for bug #29338.
mysql-test/t/sp.test:
Additional test case fix for bug #29338.
mysql-test/r/sp.result:
Additional test case fix for bug #29338.
into gleb.loc:/home/uchum/work/bk/5.1-opt
sql/item_func.h:
Auto merged
mysql-test/r/sp.result:
Merge with 5.0-opt.
mysql-test/t/sp.test:
Merge with 5.0-opt.
sql/item_func.cc:
Merge with 5.0-opt.
