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.
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.
For each view the mysqldump utility creates a temporary table
with the same name and the same columns as the view
in order to satisfy views that depend on this view.
After the creation of all tables, mysqldump drops all
temporary tables and creates actual views.
However, --skip-add-drop-table and --compact flags disable
DROP TABLE statements for those temporary tables. Thus, it was
impossible to create the views because of existence of the
temporary tables with the same names.
sometimes `mysqldump --hex-blob' overruned output buffer by '\0' byte.
The dump_table() function has been fixed to reserve 1 byte more for the
last '\0' byte of dumped string.
mysqldump didn't properly handle getting no data on
SHOW CREATE PROCEDURE. If S/C/P fails (due to dumping
user's insufficient privileges on mysql.proc, say),
mysqldump will print a comment to that effect to the
output and return an error-code. If the -f (force) option
is used, the dump will continue, otherwise, it will abort
right there and then.
Also fixes Bug#22761, "mysqldump reports no errors when using
--routines without mysql.proc privileges"
---
Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into mysql.com:/home/tnurnberg/27293/50-27293
- mysqldump executes a SHOW CREATE VIEW statement to generate the text
that it outputs. When the function name is retrieved it's database
name is unconditionally prepended. This change causes the function's
database name to be prepended only when it was used to define the
function.
The mysqldump command with both the --xml and --hex-blob options will output blob data encoded as hexBinary.
The proper XML datatype is xs:hexBinary.
The correct XML datatype is specified be setting the xsi_type attribute equal to xs:hexBinary for each encoded element.
Dumps are created for the tables in each specified database then for the views in each specified database. This bug occurs when any database's views depend on the mysql database's table data while being restored.
Added command line option --flush-privileges to the mysqldump utility which causes a FLUSH PRIVILIGES statement to be written to the dump after the mysql database.
init_dumping now accepts a function pointer to the table or view specific init_dumping function. This allows both tables and views to use the init_dumping function.
The problem was that the error handling was using a too-small buffer to
print the error message generated. We fix this by not using a buffer at
all, but by using fprintf() directly. There were also some problems with
the error handling in table dumping that was exposed by this fix that were
also corrected.
mysqldump did not select the correct database before trying to dump
views from it. this resulted in an empty result set, which in turn
startled mysql-dump into a core-dump. this only happened for views,
not for tables, and was only visible with multiple databases that
weren't by sheer luck in the order mysqldump required, anyway. this
fixes by selecting the correct database before dumping views; it also
catches the empty set-condition if it should occur for other reasons.
mysqldump did not select the correct database before trying to dump
views from it. this resulted in an empty result set, which in turn
startled mysql-dump into a core-dump. this only happened for views,
not for tables, and was only visible with multiple databases that
weren't by sheer luck in the order mysqldump required, anyway. this
fixes by selecting the correct database before dumping views; it also
catches the empty set-condition if it should occur for other reasons.
mysqldump.test calls my_print_defaults in a way that includes the systemwide
my.cnf, so the results will be beyond our control and depend on whatever the
user has in their my.cnf, namely the [mysqldump] section.
call my_print_defaults with --config-file rather than --defaults-extra-file
to prevent inclusion of system-wide defaults and use our config-file only.
