Count null_bits separately from field offsets and adjust them in case of primary key parts.
(Previously a CREATE TABLE with a lot of null fields that was part of a primary key caused MySQL to wrongly count the number of bytes needed to store null bits)
This is a more complete bug fix for #6236
if we fall back to mysql_alter_table() (for InnoDB), don't do binlogging in mysql_alter_table(), as mysql_admin_table()
is not supposed to do any binlogging (it is done by the caller).
CREATE DATABASE statement used the current database instead of the
database created when checking conditions for replication.
CREATE/DROP/ALTER DATABASE statements are now replicated based on
the manipulated database.
insertion of new records partially failed. It would get logged because of the
logic to log a partially-failed 'INSERT ... SELECT' (which can't be rolled back
in non-transactional tables), but 'CREATE TABLE ... SELECT' is always rolled
back on failure, even for non-transactional tables. (Bug #6682)
(Original fix reimplemented after review by Serg and Guilhem.)
Added auto-correct of field length for enum/set tables for ALTER TABLE
This is becasue of a bug in previous MySQL 4.1 versions where the length for enum/set was set incorrectly after ALTER TABLE
- add_field_to_list() now uses <List>String
instead of TYPELIB to be able to distinguish
literals 'aaa' and hex literals 0xaabbcc.
- move some code from add_field_to_list() where
we don't know column charset yet, to
mysql_prepare_table(), where we do.
When we are writing a transaction to the binlog, we log BEGIN/COMMIT with zero error code.
Example: all statements of trans succeeded, connection lost and so implicit rollback:
we don't want ER_NET* errors to be logged in the BEGIN/ROLLBACK events, while statement
events have 0. If there was really a serious error code, it's already in the statement events.
The idea of the fix is that the administrative statements
OPTIMIZE TABLE, REPAIR TABLE and ANALYZE TABLE should not
generate binlog errors if there is no errors on the master.
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().
(Bug #4315: GROUP_CONCAT with ORDER BY returns strange results for TEXT fields
Bug #5564: Strange behaviour with group_concat and distinct
Bug #5970: group_concat doesn't print warnings)
to auto_increment in 4.1".
Now we are enforcing NO_AUTO_VALUE_ON_ZERO mode during ALTER TABLE only
if we are converting one auto_increment column to another auto_increment
column (this also includes most common case when we don't do anything
with such column).
Also now when we convert some column to TIMESTAMP NOT NULL column with
ALTER TABLE we convert NULL values to current timestamp, (as we do this
in INSERT). One can still get old behavior by setting system TIMESTAMP
variable to 0.
