DECIMAL and TIMESTAMP used to have NUM_FLAG, but NEWDECIMAL was forgotten.
It's correct that TIMESTAMP does not have the flag nowadays (manual will be updated, connectors
developers will be notified).
when used with --tab
1) New syntax: added CHARACTER SET clause to the
SELECT ... INTO OUTFILE (to complement the same clause in
LOAD DATA INFILE).
mysqldump is updated to use this in --tab mode.
2) ESCAPED BY/ENCLOSED BY field parameters are documented as
accepting CHAR argument, however SELECT .. INTO OUTFILE
silently ignored rests of multisymbol arguments.
For the symmetrical behavior with LOAD DATA INFILE the
server has been modified to fail with the same error:
ERROR 42000: Field separator argument is not what is
expected; check the manual
3) Current LOAD DATA INFILE recognizes field/line separators
"as is" without converting from client charset to data
file charset. So, it is supposed, that input file of
LOAD DATA INFILE consists of data in one charset and
separators in other charset. For the compatibility with
that [buggy] behaviour SELECT INTO OUTFILE implementation
has been saved "as is" too, but the new warning message
has been added:
Non-ASCII separator arguments are not fully supported
This message warns on field/line separators that contain
non-ASCII symbols.
mysqldump --tab still dumped triggers to stdout rather than to
individual tables.
We now append triggers to the .sql file for the corresponding
table.
--events and --routines correspond to a database rather than a
table and will still go to stdout with --tab unless redirected
with --result-file (-r).
mysqldump.test is designed to run with concurrent inserts
disabled. It is disabling concurrent inserts at the very
beginning of the test case, and re-enables them at the
bottom of the test. But for some reason (likely incorrect
merge) we enable concurrent inserts in the middle of the test.
The problem is fixed by enabling concurrent inserts only
at the bottom of the test case.
--ignore-table option
mysqldump would correctly omit temporary tables for views, but would
incorrectly still emit all CREATE VIEW statements.
Backport a fix from 5.1, where we capture the names we want to emit
views for in one pass (the placeholder tables) and in the pass where
we actually emit the views, we don't emit a view if it wasn't in that
list.
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.
- If missing: add "disconnect <session>"
- If physical disconnect of non "default" sessions is not finished
at test end: add routine which waits till this happened
+ additional improvements like
- remove superfluous files created by the test
- replace error numbers by error names
- remove trailing spaces, replace tabs by spaces
- unify writing of bugs within comments
- correct comments
- minor changes of formatting
Modifications according to the code review are included.
Fixed tests:
grant2
grant3
lock_tables_lost_commit
mysqldump
openssl_1
outfile
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.
Merge of fixes from 5.0 -> 5.1
Moved restoration of concurrent_insert's original value to the end of the 5.1 tests
Re-recorded .result file to account for changes to test file.
Moved fix for this bug to 5.0 as other mysqldump bugs seem tied to concurrent_insert being on
Setting concurrent_insert off during this test as INSERTs weren't being
completely processed before the calls to mysqldump, resulting in failing tests.
Altered .test file to turn concurrent_insert off during the test and to restore it
to whatever the value was at the start of the test when complete.
Re-recorded .result file to account for changes to variables in the test.
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.
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.
when --master-data is used
When using the --master-data option with mysqldump, mysqldump uses
a FLUSH TABLES command. However, this statement got replicated to
the slave(s), which caused the slave(s) to block unnecessarily while
the FLUSH tables command completed.
Now, if the master-data option is set to one of the two "on" modes,
then use the "LOCAL" qualifier to ensure that it's not replicated.
between 5.0 and 5.1.
The problem was that in the patch for Bug#11986 it was decided
to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
This approach however turned out to be quite difficult to implement
properly. The main problem is to preserve the same IS-output after
dump/restore.
So, the fix is to rollback to the previous functionality, but also
to fix it to support multi-character-set-queries properly. The idea
is to generate INFORMATION_SCHEMA-query from the item-tree after
parsing view declaration. The IS-query should:
- be completely in UTF8;
- not contain character set introducers.
For more information, see WL4052.
This is *not* a fix to the bug. I'm only disabling the failing part of
mysqldump.test until the bug is fixed. Whoever fixes it, please re-enable
the test.
but not collation.
The problem here was that text literals in a view were always
dumped with character set introducer. That lead to loosing
collation information.
The fix is to dump character set introducer only if it was
in the original query. That is now possible because there
is no problem any more of loss of character set of string
literals in views -- after WL#4052 the view is dumped
in the original character set.
mysqldump adds the "-- Dump completed on YYYY-MM-DD hh:mm:ss" string
to the end of output if the --comments switch is on.
The only way to suppress this line is to use --skip-comments/--compact
switch.
New switch has been added to the mysqldump client command line:
--dump-date.
For the compatibility with previous releases, by default the --dump-date
is on.
The --dump-date switch forces mysqldump to add date to the
"-- Dump completed on ..." string at the end of output.
The --skip-dump-date switch supresses the output of date string
and uses short form of that commentary: "-- Dump completed".
--skip-comments or --compact switches disable the whole commentary
as usual.
mysqldump --skip-events --all-databases dumped data of the mysqld.event table,
and during the restoration from this dump events were created in spite
of the --skip-events option.
The mysqldump client has been modified to ignore mysql.event table data
in case of --skip-events options.
mysqldump generates view defitions in two stages:
- dump CREATE TABLE statements for the temporary tables. For each view a
temporary table, that has the same structure as the view is created.
- dump DROP TABLE statements for the temporary tables and CREATE VIEW
statements for the view.
This approach is required because views can have dependencies on each other
(a view can use other views). So, they should be created in the particular
order. mysqldump however is not smart enough, so in order to resolve
dependencies it creates temporary tables first of all.
The problem was that mysqldump might have generated incorrect dump for the
temporary table when a view has non-ASCII column name. That happened when
default-character-set is not utf8.
The fix is to:
1. Switch character_set_client for the mysqldump's connection to binary
before issuing SHOW FIELDS statement in order to avoid conversion.
2. Dump switch character_set_client statements to UTF8 and back for
CREATE TABLE statement that is issued to create temporary table.
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 dumping triggers mysqldump copied
the value of the OLD_SQL_MODE variable to the SQL_MODE
variable. If the --compact option of the mysqldump was
not set the OLD_SQL_MODE variable had the value
of the uninitialized SQL_MODE variable. So
usually the NO_AUTO_VALUE_ON_ZERO option of the
SQL_MODE variable was discarded.
This fix is for non-"--compact" mode of the mysqldump,
because mysqldump --compact never set SQL_MODE to the
value of NO_AUTO_VALUE_ON_ZERO.
The dump_triggers_for_table function has been modified
to restore previous value of the SQL_MODE variable after
dumping triggers using the SAVE_SQL_MODE temporary
variable.
