locks all rows (BUG #3300). When using innobase_locks_unsafe_for_binlog
option InnoDB does not take locks for those rows which do not
belong to the result set or werent changed by the query. This fix removes
unnecessary locks also from SELECT and DELETE queries.
Remove compiler warning 'skip_auto_inc_decr' : unreferenced local variable in Visual C++; of course, I still have to check Monty's auto-inc patch in whole
Rename innodb_table_locks_old_behavior -> innodb_table_locks
Set innodb_table_locks to off by default to get same behaviour as in MySQL 4.0.20
(This means that Innodb ignore table locks by default, which makes it easier to combine MyISAM and InnoDB to simulate a transaction)
Simple optimzations and cleanups
Removed compiler warnings and fixed portability issues
Added client functions 'mysql_embedded()' to allow client to check if we are using embedded server
Fixes for purify
Change error code to HA_ERR_ROW_IS_REFERENCED if we cannot DROP a parent table referenced by a FOREIGN KEY constraint; this error number is less misleading than the previous value HA_ERR_CANNOT_ADD_FOREIGN, but misleading still; we should introduce to 5.0 a proper MySQL error code
Fix bug #5137: if innodb_file_per_table was specified, CREATE TEMPORARY TABLE ... TYPE=InnoDB said that cannot find path specified, and made mysqld to exit(1)
Raise maximum column prefix len to 767 bytes, so that MySQL can create a column prefix index of 255 UTF-8 characters (each takes 3 bytes at the maximum); add comments about why innobase_get_at_most_n_mbchars() works ok
dict0mem.h:
Raise maximum column prefix len to 767 bytes, so that MySQL can create a column prefix index of 255 UTF-8 characters (each takes 3 bytes at the maximum)
row0mysql.c:
If MySQL tries to create a column prefix index longer that 255 UTF-8 characters, give an error, and drop the table from the InnoDB internal data dictionary. MySQL did not drop the table there in its own error handling.
A partial bugfix to a multibyte charset / column prefix index bug: my_charpos() does not handle right some cases, we try to mask the bug for ASCII chars < 128 in the UTF-8 charset
column types TIMESTAMP is NOT NULL by default, so in order to have
TIMESTAMP column holding NULL valaues you have to specify NULL as
one of its attributes (this needed for backward compatibility).
Main changes:
Replaced TABLE::timestamp_default_now/on_update_now members with
TABLE::timestamp_auto_set_type flag which is used everywhere
for determining if we should auto-set value of TIMESTAMP field
during this operation or not. We are also use Field_timestamp::set_time()
instead of handler::update_timestamp() in handlers.
This allows one to setup a master <-> master replication with non conflicting auto-increment series.
Cleaned up binary log code to make it easyer to add new state variables.
Added simpler 'upper level' logic for artificial events (events that should not cause cleanups on slave).
Simplified binary log handling.
Changed how auto_increment works together with to SET INSERT_ID=# to make it more predictable: Now the inserted rows in a multi-row statement are set independent of the existing rows in the table. (Before only InnoDB did this correctly)
Improve the comment on stored_select_lock_type
ha_innodb.cc:
Let InnoDB remember select_lock_type inside LOCK TABLES, also over plain consistent read SELECTs; fix Bug #5538 : assertion failure when using mysqldump with the -l option; in MERGING this patch to 4.1, there may be PROBLEMS; that is because previous patch was never merged to 4.1; Heikki Tuuri has to polish the code in 4.1 after this patch has been merged.
