mysqldump included character_set_client magic
that is unknown before 4.1 even when asked for
an appropriate compatibility mode.
In compatibility (3.23, 4.0) mode, we do not
output charset statements (not even in a
"comment conditional"), nor do we do magic on
the server, even if the server is sufficient
new (4.1+). Table-names will be output converted
to the charset requested by mysqldump; if such
a conversion is not possible (Ivrit -> Latin),
mysqldump will fail.
mysqldump creates stand-in tables before dumping the actual view.
Those tables were of the default type; if the view had more columns
than that (a pathological case, arguably), loading the dump would
fail. We now make the temporary stand-ins MyISAM tables to prevent
this.
binary SHOW CREATE TABLE or SELECT FROM I_S.
The problem is that mysqldump generates incorrect dump for a table
with non-ASCII column name if the mysqldump's character set is
ASCII.
The fix is to:
1. Switch character_set_client for the mysqldump's connection
to binary before issuing SHOW CREATE TABLE statement in order
to avoid conversion.
2. Dump switch character_set_client statements to UTF8 and back
for CREATE TABLE statement.
after merge fix.
range.result:
fixing result accordingly
,
cast.result:
after merge fix
range.test:
Avoid SELECT'ing of BINARY column not to output 0x00 bytes.
