he has SELECT and INSERT privileges for table with primary key"
Now we set lex->duplicates= DUP_UPDATE right in parser if INSERT has
ON DUPLICATE KEY UPDATE clause, this simplifies insert_precheck()
function (this also fixes a bug) and some other code.
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
Now we use TABLE::timestamp_field_type instead of
TABLE::timestamp_default_now/on_update_now for determining
if we should auto-set value of TIMESTAMP field during this operation.
We are also use Field_timestamp::set_time() instead of
handler::update_timestamp().
statements and negative time/date values".
The bug was in wrong sprintf format used in the client library.
The fix moves TIME -> string conversion functions to sql-common and
utilized them in the client library.
Added a try to a normal repair() if repair_by_sort() failed.
This was not done with ENABLE KEYS and OPTIMIZE TABLE.
Fixed error code handling in mysql_alter_table().
crashes server." The fix makes Item_func_rand prepared-statements
aware plus it fixes the case when RAND is used in prepared
statements and replication is on (as well as several similar issues).
Until now we did not reset THD before every execution of a prepared
statement, so if some execution had set thd->time_zone_used
or thd->rand_used they would not be reset until next mysql_parse.
Some of post-review fixes done.
BUG#4335 - one name can be handler open'ed many times.
Fixed problems detected on Windows build by VC++.
Removed unused variables.
Applied a neccessary cast.
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
A fix for Bug#6042 "constants propogation works olny once (prepared
statements)": reset item->marker in Item::cleanup, as it's used
in propogate_cond_constants. No test case as the only way I could
come up with to show the problem is EXPLAIN, and EXPLAIN is painful
to use in the test suite.