Remove `USAGE` from the `VALID_PRIVS` dict for both database and
table because it is not a valid privilege for either (and
breaks the implementation of `has_table_privilege` and
`has_database_privilege`
See http://www.postgresql.org/docs/9.0/static/sql-grant.html
Use `has_table_privileges` and `has_database_privileges`
to test whether a user already has a privilege before
granting it, or whether a user doesn't have a privilege
before revoking it.
For read-only databases, users should not change when no changes
are required.
Don't issue ALTER ROLE when role attribute flags, users password
or expiry time is not changing.
In certain cases (hashed passwords in the DB, but the password
argument is not hashed) passlib.hash is required to avoid
running ALTER ROLE.
Some places ([AWS RDS](https://forums.aws.amazon.com/thread.jspa?threadID=151248)) don't have, or don't allow, access to the `pg_authid` table. The only reason that is necessary is to check for a password change.
This flag is a workaround so passwords can only be set at creation time. It isn't as elegant as changing the password down the line, but it fixes the longstanding issue #297 that prevented this from being useful on AWS RDS.
Docs imply the mysql_variables is used to operate a single variable therefore
- fail before making any db connections if variable is not set
- validate chars for mysql variable name with re.match(^[a-z0-9_]+)
- use "SHOW VARIABLE WHERE Variable_name" instead of LIKE search
- getvariable() returns only the value or None if variable is not found
- the module returns only the found variable value instead of tuple for easier operation eg. as registere variable in tasks
Ports are integer values but the old code was assuming they were
strings. When login_port is put into playbook complex_args as an
integer the code would fail. This update should make the argument
validating make sure we have an integer and then we can send that value
directly to the relevant APIs.
Fixes#818