When the joins were not cleaned up before the tables
were closed, a JOIN_TAB still held a pointer to a
meanwhile closed table and tried to close it again
during item cleanup...
Renamed HA_VAR_LENGTH to HA_VAR_LENGTH_PART
Renamed in all files FIELD_TYPE_STRING and FIELD_TYPE_VAR_STRING to MYSQL_TYPE_STRING and MYSQL_TYPE_VAR_STRING to make it easy to catch all possible errors
Added support for VARCHAR KEYS to heap
Removed support for ISAM
Now only long VARCHAR columns are changed to TEXT on demand (not CHAR)
Internal temporary files can now use fixed length tables if the used VARCHAR columns are short
1 if the return type is int or int_fast8_t. The test case that showed
this problem is rpl000001 and the tested version was MySQL 5.0.2. The
compiler with the problem is GCC 3.0.4 runing on "Linux bitch 2.4.18
#2 Thu Apr 11 14:37:17 EDT 2002 sparc64 unknown".
By changing the return type to bool the problem disappear. (Another
way to make the problem disappear is to simply print the returned
value with printf("%d",?). The printed returned value is always 0 in
the test cases I have run.) This is only a partial solution to the
problem, since someone could later change the return type of the
function back to int or some other type that does not work.
Bug #6284 - report truncation warnings in INSERT ... SELECT only for "INSERT" part
sql/sql_insert.cc
Bug #6284 - report truncation warnings in INSERT ... SELECT only for "INSERT" part
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.
