Cleaned up (and disabled part of) date/time/datetime format patch. One can't anymore change default read/write date/time/formats.
This is becasue the non standard datetime formats can't be compared as strings and MySQL does still a lot of datetime comparisons as strings
Changed flag argument to str_to_TIME() and get_date() from bool to uint
Removed THD from str_to_xxxx functions and Item class.
Fixed core dump when doing --print-defaults
Move some common string functions to strfunc.cc
Dates as strings are now of type my_charset_bin instead of default_charset()
Introduce IDENT_QUOTED to not have to create an extra copy of simple identifiers (all chars < 128)
Removed xxx_FORMAT_TYPE enums and replaced them with the old TIMESTAMP_xxx enums
Renamed some TIMESTAMP_xxx enums to more appropriate names
Use defines instead of integers for date/time/datetime string lengths
Added to build system and use the new my_strtoll10() function.
query_alloc_block_size, query_prealloc_size, range_alloc_block_size,transaction_alloc_block_size and transaction_prealloc_size
Add more checks for "out of memory" detection in range optimization
Prepared statements in embedded server
Several changes in library code with two goals:
to make mysql_prepare_stmt working in embedded server
to get rid of #define mysql_interface_func mysql->methods->interface_func
in user's interface
For example the Binlog_dump thread (on the master) sometimes showed "Slave:".
And there were confusing messages where "binlog" was employed instead
of "relay log".
fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning"
and
fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog".
Now we don't always write the non-trans update immediately to the binlog;
if there is something in the binlog cache we write it to the binlog cache
(because the non-trans update could depend on a trans table which was modified
earlier in the transaction); then in case of ROLLBACK, we write the binlog
cache to the binlog, wrapped with BEGIN/ROLLBACK.
This guarantees that the slave does the same updates.
For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it
to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated,
we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction
terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog
(because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO
SAVEPOINT in the binlog.
Apart from this rare case of updates of mixed table types in transaction, the
usual way is still clear the binlog cache at ROLLBACK, or chop it at
ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which
is fine).
Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM".
log-slave-updates since this causes unexpected values in
Exec_master_log_pos in A->B->C replication setup, synchronization
problems in master_pos_wait()...
Still this brokes some functionality in sql/repl_failsafe.cc
(but this file is not used now)
