into mysql.com:/opt/local/work/mysql-5.0-17199
mysql-test/r/create.result:
Auto merged
mysql-test/t/create.test:
Auto merged
sql/item_strfunc.cc:
Auto merged
sql/log_event.cc:
Auto merged
sql/slave.cc:
Auto merged
sql/sp_head.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_db.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/sql_yacc.yy:
Auto merged
mysql-test/r/sp.result:
SCCS merged
mysql-test/t/sp.test:
SCCS merged
Bug#19022 "Memory bug when switching db during trigger execution"
Bug#17199 "Problem when view calls function from another database."
Bug#18444 "Fully qualified stored function names don't work correctly in
SELECT statements"
Documentation note: this patch introduces a change in behaviour of prepared
statements.
This patch adds a few new invariants with regard to how THD::db should
be used. These invariants should be preserved in future:
- one should never refer to THD::db by pointer and always make a deep copy
(strmake, strdup)
- one should never compare two databases by pointer, but use strncmp or
my_strncasecmp
- TABLE_LIST object table->db should be always initialized in the parser or
by creator of the object.
For prepared statements it means that if the current database is changed
after a statement is prepared, the database that was current at prepare
remains active. This also means that you can not prepare a statement that
implicitly refers to the current database if the latter is not set.
This is not documented, and therefore needs documentation. This is NOT a
change in behavior for almost all SQL statements except:
- ALTER TABLE t1 RENAME t2
- OPTIMIZE TABLE t1
- ANALYZE TABLE t1
- TRUNCATE TABLE t1 --
until this patch t1 or t2 could be evaluated at the first execution of
prepared statement.
CURRENT_DATABASE() still works OK and is evaluated at every execution
of prepared statement.
Note, that in stored routines this is not an issue as the default
database is the database of the stored procedure and "use" statement
is prohibited in stored routines.
This patch makes obsolete the use of check_db_used (it was never used in the
old code too) and all other places that check for table->db and assign it
from THD::db if it's NULL, except the parser.
How this patch was created: THD::{db,db_length} were replaced with a
LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
manually checked and:
- if the place uses thd->db by pointer, it was fixed to make a deep copy
- if a place compared two db pointers, it was fixed to compare them by value
(via strcmp/my_strcasecmp, whatever was approproate)
Then this intermediate patch was used to write a smaller patch that does the
same thing but without a rename.
TODO in 5.1:
- remove check_db_used
- deploy THD::set_db in mysql_change_db
See also comments to individual files.
mysql-test/r/create.result:
Modify the result file: a database can never be NULL.
mysql-test/r/ps.result:
Update test results (Bug#17199 et al)
mysql-test/r/sp.result:
Update test results (Bug#17199 et al)
mysql-test/t/create.test:
Update the id of the returned error.
mysql-test/t/ps.test:
Add test coverage for prepared statements and current database. In scope of
work on Bug#17199 "Problem when view calls function from another database."
mysql-test/t/sp.test:
Add a test case for Bug#17199 "Problem when view calls function from another
database." and Bug#18444 "Fully qualified stored function names don't work
correctly in SELECT statements". Test a complementary problem.
sql/item_strfunc.cc:
Touch the code that reads thd->db (cleanup).
sql/log_event.cc:
While we are at it, replace direct access to thd->db with a method.
Should simplify future conversion of THD::db to LEX_STRING.
sql/slave.cc:
While we are at it, replace direct access to thd->db with a method.
Should simplify future conversion of THD::db to LEX_STRING.
sql/slave.h:
Remove a declaration for a method that is used only in one module.
sql/sp.cc:
Rewrite sp_use_new_db: this is a cleanup that I needed in order to understand
this function and ensure that it has no bugs.
sql/sp.h:
Add a new declaration for sp_use_new_db (uses LEX_STRINGs) and a comment.
sql/sp_head.cc:
- drop sp_name_current_db_new - a creator of sp_name class that was used
when sp_name was created for an identifier without an explicitly initialized
database. Now we pass thd->db to constructor of sp_name right in the
parser.
- rewrite sp_head::init_strings: name->m_db is always set now
- use the new variant of sp_use_new_db
- we don't need to update thd->db with SP MEM_ROOT pointer anymore when
parsing a stored procedure, as noone will refer to it (yes!)
sql/sp_head.h:
- remove unneded methods and members
sql/sql_class.h:
- introduce 3 THD methods to work with THD::db:
.set_db to assign the current database
.reset_db to reset the current database (temporarily) or set it to NULL
.opt_copy_db_to - to deep-copy thd->db to a pointer if it's not NULL
sql/sql_db.cc:
While we are at it, replace direct access to thd->db with a method.
Should simplify future conversion of THD::db to LEX_STRING.
sql/sql_insert.cc:
- replace checks with asserts: table_list->db must be always set in the parser.
sql/sql_lex.h:
- add a comment
sql/sql_parse.cc:
- implement the invariant described in the changeset comment.
- remove juggling with lex->sphead in SQLCOM_CREATE_PROCEDURE:
now db_load_routine uses its own LEX object and doesn't damage the main
LEX.
- add DBUG_ASSERT(0) to unused "check_db_used"
sql/sql_table.cc:
- replace a check with an assert (table_ident->db)
sql/sql_trigger.cc:
While we are at it, replace direct access to thd->db with a method.
Should simplify future conversion of THD::db to LEX_STRING.
sql/sql_udf.cc:
- use thd->set_db instead of direct modification of to thd->db
sql/sql_view.cc:
- replace a check with an assert (view->db)
sql/sql_yacc.yy:
- make sure that we always copy table->db or name->db or ident->db or
select_lex->db from thd->db if the former is not set. If thd->db
is not set but is accessed, return an error.
sql/tztime.cc:
- be nice, never copy thd->db by pointer.
Bug#19022 "Memory bug when switching db during trigger execution"
Bug#17199 "Problem when view calls function from another database."
Bug#18444 "Fully qualified stored function names don't work correctly in
SELECT statements"
Documentation note: this patch introduces a change in behaviour of prepared
statements.
This patch adds a few new invariants with regard to how THD::db should
be used. These invariants should be preserved in future:
- one should never refer to THD::db by pointer and always make a deep copy
(strmake, strdup)
- one should never compare two databases by pointer, but use strncmp or
my_strncasecmp
- TABLE_LIST object table->db should be always initialized in the parser or
by creator of the object.
For prepared statements it means that if the current database is changed
after a statement is prepared, the database that was current at prepare
remains active. This also means that you can not prepare a statement that
implicitly refers to the current database if the latter is not set.
This is not documented, and therefore needs documentation. This is NOT a
change in behavior for almost all SQL statements except:
- ALTER TABLE t1 RENAME t2
- OPTIMIZE TABLE t1
- ANALYZE TABLE t1
- TRUNCATE TABLE t1 --
until this patch t1 or t2 could be evaluated at the first execution of
prepared statement.
CURRENT_DATABASE() still works OK and is evaluated at every execution
of prepared statement.
Note, that in stored routines this is not an issue as the default
database is the database of the stored procedure and "use" statement
is prohibited in stored routines.
This patch makes obsolete the use of check_db_used (it was never used in the
old code too) and all other places that check for table->db and assign it
from THD::db if it's NULL, except the parser.
How this patch was created: THD::{db,db_length} were replaced with a
LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
manually checked and:
- if the place uses thd->db by pointer, it was fixed to make a deep copy
- if a place compared two db pointers, it was fixed to compare them by value
(via strcmp/my_strcasecmp, whatever was approproate)
Then this intermediate patch was used to write a smaller patch that does the
same thing but without a rename.
TODO in 5.1:
- remove check_db_used
- deploy THD::set_db in mysql_change_db
See also comments to individual files.
Bug#17294 - INSERT DELAYED puting an \n before data
Bug#16611 - INSERT DELAYED corrupts data
Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
Combined as Bug#16218.
INSERT DELAYED crashed in 5.0 on a table with a varchar that
could be NULL and was created pre-5.0 (Bugs 16218 and 13707).
INSERT DELAYED corrupted data in 5.0 on a table with varchar
fields that was created pre-5.0 (Bugs 17294 and 16611).
In case of INSERT DELAYED the open table is copied from the
delayed insert thread to be able to create a record for the
queue. When copying the fields, a method was used that did
convert old varchar to new varchar fields and did not set up
some pointers into the record buffer of the table.
The field conversion was guilty for the misinterpretation of
the record contents by the delayed insert thread. The wrong
pointer setup was guilty for the crashes.
For Bug 13707 (Server crash with INSERT DELAYED on MyISAM table)
I fixed the above mentioned method to set up one of the pointers.
For Bug 16218 I set up the other pointers too.
But when looking at the corruptions I got aware that converting
the field type was totally wrong for INSERT DELAYED. The copied
table is used to create a record that is to be sent to the
delayed insert thread. Of course it can interpret the record
correctly only if all field types are the same in both table
objects.
So I revoked the fix for Bug 13707 and changed the new_field()
method so that it can suppress conversions.
No test case as this is a migration problem. One needs to
create a table with 4.x and use it with 5.x. I added two
test scripts to the bug report.
sql/field.cc:
Bug#16218 - Crash on insert delayed
Bug#17294 - INSERT DELAYED puting an \n before data
Bug#16611 - INSERT DELAYED corrupts data
Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
Combined as Bug#16218.
Added parameter 'keep_type' to Field::new_field().
Undid the change from Bug 13707 (Server crash with INSERT
DELAYED on MyISAM table).
I solved all four bugs in sql/sql_insert.cc by making exact
duplicates of the fields. The new_field() method converts
certain field types, which is wrong for INSERT DELAYED.
sql/field.h:
Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
Combined as Bug#16218.
Added parameter 'keep_type' to Field::new_field().
sql/sql_insert.cc:
Bug#16218 - Crash on insert delayed
Bug#17294 - INSERT DELAYED puting an \n before data
Bug#16611 - INSERT DELAYED corrupts data
Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
Combined as Bug#16218.
Added comments. Made small style fixes.
Used the new parameter 'keep_type' of Field::new_field()
to avoid field type conversion. The table copy must have
exactly the same types of fields as the original table.
Otherwise the record contents created by the foreground
thread could be misinterpreted by the delayed insert thread.
sql/sql_select.cc:
Bug#16218 - Crash on insert delayed
Bug#17294 - INSERT DELAYED puting an \n before data
Bug#16611 - INSERT DELAYED corrupts data
Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
Combined as Bug#16218.
Added parameter 'keep_type' to Field::new_field().
Undid the change from Bug 13707 (Server crash with INSERT
DELAYED on MyISAM table).
I solved all four bugs in sql/sql_insert.cc by making exact
duplicates of the fields. The new_field() method converts
certain field types, which is wrong for INSERT DELAYED.
sql/sql_trigger.cc:
Bug#16218 - Crash on insert delayed
Bug#17294 - INSERT DELAYED puting an \n before data
Bug#16611 - INSERT DELAYED corrupts data
Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
Combined as Bug#16218.
Added parameter 'keep_type' to Field::new_field().
Undid the change from Bug 13707 (Server crash with INSERT
DELAYED on MyISAM table).
I solved all four bugs in sql/sql_insert.cc by making exact
duplicates of the fields. The new_field() method converts
certain field types, which is wrong for INSERT DELAYED.
sql/table.cc:
Bug#16218 - Crash on insert delayed
Bug#17294 - INSERT DELAYED puting an \n before data
Bug#16611 - INSERT DELAYED corrupts data
Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
Combined as Bug#16218.
Added parameter 'keep_type' to Field::new_field().
Undid the change from Bug 13707 (Server crash with INSERT
DELAYED on MyISAM table).
I solved all four bugs in sql/sql_insert.cc by making exact
duplicates of the fields. The new_field() method converts
certain field types, which is wrong for INSERT DELAYED.
Bug#17294 - INSERT DELAYED puting an \n before data
Bug#16611 - INSERT DELAYED corrupts data
Bug#13707 - Server crash with INSERT DELAYED on MyISAM table
Combined as Bug#16218.
INSERT DELAYED crashed in 5.0 on a table with a varchar that
could be NULL and was created pre-5.0 (Bugs 16218 and 13707).
INSERT DELAYED corrupted data in 5.0 on a table with varchar
fields that was created pre-5.0 (Bugs 17294 and 16611).
In case of INSERT DELAYED the open table is copied from the
delayed insert thread to be able to create a record for the
queue. When copying the fields, a method was used that did
convert old varchar to new varchar fields and did not set up
some pointers into the record buffer of the table.
The field conversion was guilty for the misinterpretation of
the record contents by the delayed insert thread. The wrong
pointer setup was guilty for the crashes.
For Bug 13707 (Server crash with INSERT DELAYED on MyISAM table)
I fixed the above mentioned method to set up one of the pointers.
For Bug 16218 I set up the other pointers too.
But when looking at the corruptions I got aware that converting
the field type was totally wrong for INSERT DELAYED. The copied
table is used to create a record that is to be sent to the
delayed insert thread. Of course it can interpret the record
correctly only if all field types are the same in both table
objects.
So I revoked the fix for Bug 13707 and changed the new_field()
method so that it can suppress conversions.
No test case as this is a migration problem. One needs to
create a table with 4.x and use it with 5.x. I added two
test scripts to the bug report.
Addendum fixes after changing the condition variable
for the global read lock.
The stress test suite revealed some deadlocks. Some were
related to the new condition variable (COND_global_read_lock)
and some were general problems with the global read lock.
It is now necessary to signal COND_global_read_lock whenever
COND_refresh is signalled.
We need to wait for the release of a global read lock if one
is set before every operation that requires a write lock.
But we must not wait if we have locked tables by LOCK TABLES.
After setting a global read lock a thread waits until all
write locks are released.
mysql-test/r/lock_multi.result:
Bug#16986 - Deadlock condition with MyISAM tables
Addendum fixes after changing the condition variable
for the global read lock.
Added test results.
mysql-test/t/lock_multi.test:
Bug#16986 - Deadlock condition with MyISAM tables
Addendum fixes after changing the condition variable
for the global read lock.
Added tests for possible deadlocks that did not occur
with the stress test suite.
mysys/thr_lock.c:
Bug#16986 - Deadlock condition with MyISAM tables
Addendum fixes after changing the condition variable
for the global read lock.
Added a protection against an infinite loop that occurs
with the test case for Bug #20662.
sql/lock.cc:
Bug#16986 - Deadlock condition with MyISAM tables
Addendum fixes after changing the condition variable
for the global read lock.
Signal COND_global_read_lock whenever COND_refresh
is signalled by using the new function broadcast_refresh().
Added the definition of a new function that signals
COND_global_read_lock whenever COND_refresh is signalled.
sql/mysql_priv.h:
Bug#16986 - Deadlock condition with MyISAM tables
Addendum fixes after changing the condition variable
for the global read lock.
Added a declaration for a new function that signals
COND_global_read_lock whenever COND_refresh is signalled.
sql/sql_base.cc:
Bug#16986 - Deadlock condition with MyISAM tables
Addendum fixes after changing the condition variable
for the global read lock.
Signal COND_global_read_lock whenever COND_refresh
is signalled by using the new function broadcast_refresh().
sql/sql_handler.cc:
Bug#16986 - Deadlock condition with MyISAM tables
Addendum fixes after changing the condition variable
for the global read lock.
Signal COND_global_read_lock whenever COND_refresh
is signalled by using the new function broadcast_refresh().
sql/sql_insert.cc:
Bug#16986 - Deadlock condition with MyISAM tables
Addendum fixes after changing the condition variable
for the global read lock.
Removed global read lock handling from inside of
INSERT DELAYED. It is handled on a higher level now.
sql/sql_parse.cc:
Bug#16986 - Deadlock condition with MyISAM tables
Addendum fixes after changing the condition variable
for the global read lock.
Wait for the release of a global read lock if one is set
before every operation that requires a write lock.
But don't wait if locked tables exist already.
sql/sql_table.cc:
Bug#16986 - Deadlock condition with MyISAM tables
Addendum fixes after changing the condition variable
for the global read lock.
Removed global read lock handling from inside of
CREATE TABLE. It is handled on a higher level now.
Signal COND_global_read_lock whenever COND_refresh
is signalled by using the new function broadcast_refresh().
Addendum fixes after changing the condition variable
for the global read lock.
The stress test suite revealed some deadlocks. Some were
related to the new condition variable (COND_global_read_lock)
and some were general problems with the global read lock.
It is now necessary to signal COND_global_read_lock whenever
COND_refresh is signalled.
We need to wait for the release of a global read lock if one
is set before every operation that requires a write lock.
But we must not wait if we have locked tables by LOCK TABLES.
After setting a global read lock a thread waits until all
write locks are released.
into dator5.(none):/home/pappa/bug17138
mysql-test/r/partition.result:
Auto merged
mysql-test/t/partition.test:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_table.cc:
Auto merged
sql/handler.cc:
Generating table maps from all locks that can be available: THD::extra_lock,
THD::lock, and THD::locked_tables.
sql/sql_class.h:
Adding member Open_tables:state::extra_lock to hold the extra lock used by select_create.
Removing select_insert::lock.
sql/sql_insert.cc:
Adding member Open_tables:state::extra_lock to hold the extra lock used by select_create.
Removing select_insert::lock.
Review comments
mysql-test/t/partition.test:
Changed procedure names ensured procedures were dropped
sql/ha_ndbcluster.h:
Improved name of method
sql/ha_partition.h:
Improved name of method
sql/handler.h:
Improved name of method
Removed deprecated constants
sql/item_sum.cc:
Improved name of method
sql/sql_acl.cc:
Improved name of method
sql/sql_insert.cc:
Removed use of HA_WRITE_SKIP and introduced is_fatal_error instead
sql/sql_select.cc:
Improved name of method
sql/sql_table.cc:
Improved name of method
Reintroduced dead code for future possible use
sql/sql_union.cc:
Improved name of method
sql/sql_update.cc:
Improved name of method
Need to flag when a copy is needed to not overwrite a create_info
object connected to the lex structure
sql/mysql_priv.h:
Need to flag when a copy is needed to not overwrite a create_info
object connected to the lex structure
sql/sql_insert.cc:
Need to flag when a copy is needed to not overwrite a create_info
object connected to the lex structure
sql/sql_parse.cc:
Need to flag when a copy is needed to not overwrite a create_info
object connected to the lex structure
sql/sql_table.cc:
Need to flag when a copy is needed to not overwrite a create_info
object connected to the lex structure
though unneeded". It's indeed unneeded, as slave is only interested in
permanent tables, and permanent tables don't depend on temporary tables
when in row-based binlogging mode. And other CREATE TEMPORARY TABLE
(referring no table or with LIKE) already don't write the CREATE to
binlog in row-based mode.
mysql-test/r/rpl_row_create_table.result:
result update (note that no lines appear in SHOW BINLOG EVENTS further below, which is how we
see the bug is fixed)
mysql-test/t/rpl_row_create_table.test:
testing if a CREATE TEMPORARY TABLE SELECT goes to binlog (it should not)
when in row-based binlogging mode. A few lines after, there is a SHOW
BINLOG EVENTS; before the bugfix it showed the CREATE TEMPORARY TABLE.
sql/sql_class.h:
a method to access select_create::create_info from outside of select_create
("read-only" access). Making get_thd() "read-only" too.
sql/sql_insert.cc:
The function (hook) which writes CREATE TABLE to binlog when in row-based
binlogging mode, for CREATE TABLE SELECT, now does nothing if the table
is temporary (as in row-based mode, temp tables are not replicated).
This is consistent with CREATE TEMPORARY TABLE LIKE and
CREATE TEMPORARY TABLE, which don't write any CREATE to binlog in row-based
mode.
though unneeded". It's indeed unneeded, as slave is only interested in
permanent tables, and permanent tables don't depend on temporary tables
when in row-based binlogging mode. And other CREATE TEMPORARY TABLE
(referring no table or with LIKE) already don't write the CREATE to
binlog in row-based mode.
into dator5.(none):/home/pappa/bug17138
mysql-test/t/partition.test:
Auto merged
sql/handler.h:
Auto merged
sql/sql_acl.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_table.cc:
Auto merged
a fatal error. New handling of ignore error in place.
mysql-test/t/partition.test:
New test case
sql/ha_ndbcluster.h:
New handler method to check if error can be ignored
sql/ha_partition.h:
New handler method to check if error can be ignored
sql/handler.h:
New handler method to check if error can be ignored
sql/sql_acl.cc:
Use new handler method
sql/sql_insert.cc:
Use new handler method
sql/sql_table.cc:
Use new handler method
sql/sql_union.cc:
Use new handler method
sql/sql_update.cc:
Use new handler method
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.1-merge
mysql-test/t/archive.test:
Auto merged
sql/log.cc:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_table.cc:
Auto merged
configure.in:
Auto merged
client/mysqlbinlog.cc:
Auto merged
mysql-test/mysql-test-run.pl:
Auto merged
mysql-test/r/archive.result:
Auto merged
mysql-test/r/auto_increment.result:
Auto merged
mysql-test/r/cast.result:
Auto merged
mysql-test/r/ctype_utf8.result:
Auto merged
mysql-test/r/func_group.result:
Auto merged
mysql-test/r/func_str.result:
Auto merged
mysql-test/r/func_time.result:
Auto merged
mysql-test/r/multi_update.result:
Auto merged
mysql-test/r/ndb_lock.result:
Auto merged
mysql-test/r/replace.result:
Auto merged
mysql-test/r/union.result:
Auto merged
mysql-test/t/archive.test:
Auto merged
mysql-test/t/auto_increment.test:
Auto merged
mysql-test/t/delayed.test:
Auto merged
mysql-test/t/func_time.test:
Auto merged
mysql-test/t/multi_update.test:
Auto merged
mysql-test/t/ndb_lock.test:
Auto merged
mysql-test/t/select.test:
Auto merged
sql/field.cc:
Auto merged
sql/ha_ndbcluster.cc:
Auto merged
sql/item.h:
Auto merged
sql/item_cmpfunc.h:
Auto merged
sql/item_func.cc:
Auto merged
sql/item_strfunc.cc:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/opt_range.cc:
Auto merged
sql/opt_sum.cc:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_class.h:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_lex.cc:
Auto merged
sql/sql_lex.h:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_select.h:
Auto merged
sql/sql_yacc.yy:
Auto merged
sql/structs.h:
Auto merged
storage/archive/ha_archive.cc:
Auto merged
tests/mysql_client_test.c:
Auto merged
INSERT triggers".
In cases when REPLACE was internally executed via update and table had
on update (on delete) triggers defined we exposed the fact that such
optimization used by callng on update (not calling on delete) triggers.
Such behavior contradicts our documentation which describes REPLACE as
INSERT with optional DELETE.
This fix just disables this optimization for tables with on delete triggers.
The optimization is still applied for tables which have on update but have
no on delete triggers, we just don't invoke on update triggers in this case
and thus don't expose information about optimization to user.
Also added test coverage for values returned by ROW_COUNT() function (and
thus for values returned by mysql_affected_rows()) for various forms of
INSERT.
mysql-test/r/insert.result:
Added test for values returned by ROW_COUNT() function (and thus for values
returned by mysql_affected_rows()) for various forms of INSERT. We didn't
have coverage for this before and since this fix touches related code it is
better to add it now.
mysql-test/r/trigger.result:
Adjusted test after fixing bug#13479 "REPLACE activates UPDATE trigger, not
the DELETE and INSERT triggers".
mysql-test/t/insert.test:
Added test for values returned by ROW_COUNT() function (and thus for values
returned by mysql_affected_rows()) for various forms of INSERT. We didn't
have coverage for this before and since this fix touches related code it is
better to add it now.
mysql-test/t/trigger.test:
Adjusted test after fixing bug#13479 "REPLACE activates UPDATE trigger, not
the DELETE and INSERT triggers".
sql/sql_insert.cc:
write_record():
We should not expose that internally we sometimes execute REPLACE
via UPDATE instead of documented INSERT + DELETE pair. So we should not
use this optimization for tables with on delete triggers. OTOH it is ok
to use it for tables which have on update but have no on delete triggers,
we just should not invoke on update triggers in this case.
INSERT triggers".
In cases when REPLACE was internally executed via update and table had
on update (on delete) triggers defined we exposed the fact that such
optimization used by callng on update (not calling on delete) triggers.
Such behavior contradicts our documentation which describes REPLACE as
INSERT with optional DELETE.
This fix just disables this optimization for tables with on delete triggers.
The optimization is still applied for tables which have on update but have
no on delete triggers, we just don't invoke on update triggers in this case
and thus don't expose information about optimization to user.
Also added test coverage for values returned by ROW_COUNT() function (and
thus for values returned by mysql_affected_rows()) for various forms of
INSERT.
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.1-merge
mysql-test/r/binlog_row_mix_innodb_myisam.result:
Auto merged
mysql-test/r/federated.result:
Auto merged
mysql-test/r/innodb.result:
Auto merged
mysql-test/extra/rpl_tests/rpl_ddl.test:
Auto merged
mysql-test/r/rpl_ddl.result:
Auto merged
mysql-test/r/sp-error.result:
Auto merged
mysql-test/r/sp.result:
Auto merged
mysql-test/r/rpl_ndb_charset.result:
Auto merged
mysql-test/r/type_ranges.result:
Auto merged
mysql-test/r/view.result:
Auto merged
mysql-test/r/trigger-grant.result:
Auto merged
mysql-test/t/archive.test:
Auto merged
mysql-test/t/create.test:
Auto merged
mysql-test/t/disabled.def:
Auto merged
mysql-test/t/federated.test:
Auto merged
mysql-test/t/innodb.test:
Auto merged
mysql-test/t/innodb_mysql.test:
Auto merged
mysql-test/t/sp.test:
Auto merged
mysql-test/t/trigger-grant.test:
Auto merged
mysql-test/t/view.test:
Auto merged
sql/ha_innodb.cc:
Auto merged
sql/log.cc:
Auto merged
sql/log_event.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/set_var.h:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
mysql-test/r/create.result:
Manual merge
mysql-test/r/innodb_mysql.result:
Manual merge
sql/handler.cc:
Manual merge
sql/share/errmsg.txt:
Manual merge
sql/sql_class.h:
Manual merge
sql/sql_delete.cc:
Manual merge
sql/sql_insert.cc:
Manual merge
sql/sql_table.cc:
Manual merge
