From the documentation it is not immediately clear that the 'target'
option refers to a location on the remote host. This change emphasizes that.
In addition to .sql files, .bz2 and .gz files are supported for dumps and
restores. This is now documented.
The SET GLOBAL statement requires properly quoting of values. For example, the
following correct queries will fail if quotes are toggled:
mysql> SET GLOBAL innodb_lru_scan_depth = 2000;
mysql> SET GLOBAL master_info_repository = "TABLE";
`mysql_variable` module doesn't quote the value argument, therefore
string values will fail.
# this task will pass, 2000 is passed without quotes
- name: set a numeric value
mysql_variable: variable=innodb_lru_scan_depth value=2000
# this task will fail, TABLE is passed without quotes
- name: set a string value
mysql_variable: variable=master_info_repository value=TABLE
With this patch prepared statements are used. Proper quoting will be
done automatically based on the type of the variables thus an attempt
to convert to int, then to float is done in first place.
Booleans values, ie: ON, OFF, are not specially handled because they
can be quoted. For example, the following queries are correct and
equivalent, they all set _innodb_file_per_table_ to logical _True_:
mysql> SET GLOBAL innodb_file_per_table = "ON";
mysql> SET GLOBAL innodb_file_per_table = ON;
mysql> SET GLOBAL innodb_file_per_table = 1;
Tested in mysql 5.5 and 5.6.
Previously postgresql_user quoted user supplied identifers to create
grant statements that look like this:
GRANT SELECT on "tablename" to "user";
Which only works if the tablename is not in a namespace. If you supply
a namespaced tabelname like "report.revenue" then it creates this
incorrect statement:
GRANT SELECT on "report.revenue" to "user";
Which will not find the "revenue" table in the "report" namespace, but
will rather look for a table named "report.revenue" in the current
(default public) namespace. The correct form is:
GRANT SELECT on "report"."revenue" to "user";
This approach could have the unfortunate effect that code that
previously relied on the other behavior to grant privileges on tables
with periods in their names may now break. PostgreSQL users
typically shouldn't name tables as such, and users can still access the
old behavior and use tablenames with periods in the if they must by
supplying their own quoting.
The password is passed on a command line for dump and import and needs
quoting.
Ideally, this would not be passed on a command line at all - any ideas?
Or at least have a stronger form of quoting so that embedded single
quotes will be escaped.
mysql_variables bindly executes a SET var = value query even when
the variable already has the requested value.
With this patch the query is executed only if the current value is
different to the requested one.
When revoking privileges from a user, the GRANT OPTION is always
revoked, even if the user doesn't have it. If the user exists, this
doesn't give an error, but if the user doesn't exist, it does:
mysql> GRANT ALL ON test.* TO 'test'@'localhost';
Query OK, 0 rows affected (0.00 sec)
mysql> REVOKE GRANT OPTION ON test.* FROM 'test'@'localhost';
Query OK, 0 rows affected (0.00 sec)
mysql> REVOKE GRANT OPTION ON test.* FROM 'test'@'localhost';
Query OK, 0 rows affected (0.00 sec)
mysql> REVOKE ALL ON test.* FROM 'test'@'localhost';
Query OK, 0 rows affected (0.00 sec)
mysql> REVOKE GRANT OPTION ON test.* FROM 'test'@'localhost';
ERROR 1141 (42000): There is no such grant defined for user 'test' on
host 'localhost'
Additionally, in MySQL 5.6 this breaks replication because of
http://bugs.mysql.com/bug.php?id=68892.
Rather than revoking the GRANT OPTION and catching the error, check if
the user actually has it and only revoke it when he does.
Migrated all examples: in DOCUMENTATION=''' string to standalone EXAMPLES=''' string
Added deprecation warning to moduledev.rst and remove deprecated example from it
Fixed up a few typos and uppercased some acronyms.
add consistency to how EXAMPLES are formatted
In MySQL 5.6, the root account created by default during MySQL
installation has the PROXY ... WITH GRANT OPTION privilege for ''@'',
that is, for all users.
The mysql_user module tries to revoke this privilege, but this fails:
_mysql_exceptions.ProgrammingError: (1064, "You have an error in your
SQL syntax; check the manual that corresponds to your MySQL server
version for the right syntax to use near '''@'' FROM 'root'@'localhost''
at line 1")
Quick fix: don't revoke privilege if user is root and the privilege to
revoke contains PROXY.
