GRANTpriv_type
[(column_list
)] [,priv_type
[(column_list
)]] ... ON [object_type
]priv_level
TOuser
[IDENTIFIED BY [PASSWORD] 'password
'] [,user
[IDENTIFIED BY [PASSWORD] 'password
']] ... [REQUIRE {NONE |ssl_option
[[AND]ssl_option
] ...}] [WITHwith_option
...]object_type
: TABLE | FUNCTION | PROCEDUREpriv_level
: * | *.* |db_name
.* |db_name.tbl_name
|tbl_name
|db_name
.routine_name
ssl_option
: SSL | X509 | CIPHER 'cipher
' | ISSUER 'issuer
' | SUBJECT 'subject
'with_option
: GRANT OPTION | MAX_QUERIES_PER_HOURcount
| MAX_UPDATES_PER_HOURcount
| MAX_CONNECTIONS_PER_HOURcount
| MAX_USER_CONNECTIONScount
The GRANT
statement enables
system administrators to grant privileges to MySQL user
accounts. GRANT
also serves to
specify other account characteristics such as use of secure
connections and limits on access to server resources. To use
GRANT
, you must have the
GRANT OPTION
privilege, and you
must have the privileges that you are granting.
Normally, CREATE USER
is used to
create an account and GRANT
to
define its privileges. However, if an account named in a
GRANT
statement does not already
exist, GRANT
may create it under
the conditions described later in the discussion of the
NO_AUTO_CREATE_USER
SQL mode.
The REVOKE
statement is related
to GRANT
and enables
administrators to remove account privileges. To determine what
privileges an account has, use SHOW
GRANTS
. See Section 12.4.1.5, “REVOKE
Syntax”, and
Section 12.4.5.22, “SHOW GRANTS
Syntax”.
Some releases of MySQL introduce changes to the structure of the grant tables to add new privileges or features. Whenever you update to a new version of MySQL, you should update your grant tables to make sure that they have the current structure so that you can take advantage of any new capabilities. See Section 4.4.7, “mysql_upgrade — Check Tables for MySQL Upgrade”.
MySQL Enterprise. For automated notification of users with inappropriate privileges, subscribe to the MySQL Enterprise Monitor. For more information, see http://www.mysql.com/products/enterprise/advisors.html.
The following table summarizes the allowable
priv_type
privilege types that can be
specified for the GRANT
and
REVOKE
statements. For additional
information about these privileges, see
Section 5.4.1, “Privileges Provided by MySQL”.
Privilege | Meaning |
ALL [PRIVILEGES] |
Grant all privileges at specified access level except
GRANT OPTION
|
ALTER |
Enable use of ALTER TABLE
|
ALTER ROUTINE |
Enable stored routines to be altered or dropped |
CREATE |
Enable database and table creation |
CREATE ROUTINE |
Enable stored routine creation |
CREATE TEMPORARY TABLES |
Enable use of CREATE
TEMPORARY TABLE
|
CREATE USER |
Enable use of CREATE USER ,
DROP USER ,
RENAME USER , and
REVOKE ALL
PRIVILEGES
|
CREATE VIEW |
Enable views to be created or altered |
DELETE |
Enable use of DELETE
|
DROP |
Enable databases, tables, and views to be dropped |
EVENT |
Enable use of events for the Event Scheduler |
EXECUTE |
Enable the user to execute stored routines |
FILE |
Enable the user to cause the server to read or write files |
GRANT OPTION |
Enable privileges to be granted to or removed from other accounts |
INDEX |
Enable indexes to be created or dropped |
INSERT |
Enable use of INSERT
|
LOCK TABLES |
Enable use of LOCK TABLES on tables for
which you have the SELECT
privilege |
PROCESS |
Enable the user to see all processes with SHOW
PROCESSLIST
|
REFERENCES |
Not implemented |
RELOAD |
Enable use of FLUSH operations |
REPLICATION CLIENT |
Enable the user to ask where master or slave servers are |
REPLICATION SLAVE |
Enable replication slaves to read binary log events from the master |
SELECT |
Enable use of SELECT
|
SHOW DATABASES |
Enable SHOW DATABASES to show all
databases |
SHOW VIEW |
Enable use of SHOW CREATE VIEW
|
SHUTDOWN |
Enable use of mysqladmin shutdown |
SUPER |
Enable use of other adminstrative operations such as
CHANGE MASTER TO ,
KILL ,
PURGE BINARY LOGS ,
SET
GLOBAL , and mysqladmin
debug command |
TRIGGER |
Enable triggers to be created or dropped |
UPDATE |
Enable use of UPDATE
|
USAGE |
Synonym for “no privileges” |
A trigger is associated with a table, so to create or drop a
trigger, you must have the
TRIGGER
privilege for the table,
not the trigger.
In GRANT
statements, the
ALL [PRIVILEGES]
privilege is named by itself and cannot be specified along with
other privileges. It stands for all privileges available for the
level at which privileges are to be granted except for the
GRANT OPTION
privilege.
USAGE
can be specified when you
want to create a user that has no privileges, or to specify the
REQUIRE
or WITH
clauses
for an account without changing its existing privileges.
MySQL account information is stored in the tables of the
mysql
database. This database and the access
control system are discussed extensively in
Chapter 5, MySQL Server Administration, which you should
consult for additional details.
If the grant tables hold privilege rows that contain mixed-case
database or table names and the
lower_case_table_names
system
variable is set to a nonzero value,
REVOKE
cannot be used to revoke
these privileges. It will be necessary to manipulate the grant
tables directly. (GRANT
will not
create such rows when
lower_case_table_names
is set,
but such rows might have been created prior to setting the
variable.)
Privileges can be granted at several levels, depending on the
syntax used for the ON
clause. For
REVOKE
, the same
ON
syntax specifies which privileges to take
away. The examples shown here include no IDENTIFIED BY
'
clause for
brevity, but you should include one if the account does not
already exist to avoid creating an account with no password.
password
'
Global Privileges
Global privileges are administrative or apply to all databases
on a given server. To assign global privileges, use ON
*.*
syntax:
GRANT ALL ON *.* TO 'someuser'@'somehost'; GRANT SELECT, INSERT ON *.* TO 'someuser'@'somehost';
The CREATE USER
,
FILE
,
PROCESS
,
RELOAD
,
REPLICATION CLIENT
,
REPLICATION SLAVE
,
SHOW DATABASES
,
SHUTDOWN
, and
SUPER
privileges are
administrative and can only be granted globally.
Other privileges can be granted globally or at more specific levels.
Global privileges are stored in the
mysql.user
table.
Database Privileges
Database privileges apply to all objects in a given database. To
assign database-level privileges, use ON
syntax:
db_name
.*
GRANT ALL ON mydb.* TO 'someuser'@'somehost'; GRANT SELECT, INSERT ON mydb.* TO 'someuser'@'somehost';
Privileges also are assigned at the database level (for the
default database) if you use ON *
syntax and
you have selected a default database.
The CREATE
,
DROP
,
EVENT
, and
GRANT OPTION
privileges can be
specified at the database level. Table or routine privileges
also can be specified at the database level, in which case they
apply to all tables or routines in the database.
Database privileges are stored in the
mysql.db
and mysql.host
tables. GRANT
and
REVOKE
affect the
db
table, but not the host
table, which is rarely used.
Table Privileges
Table privileges apply to all columns in a given table. To
assign table-level privileges, use ON
syntax:
db_name.tbl_name
GRANT ALL ON mydb.mytbl TO 'someuser'@'somehost'; GRANT SELECT, INSERT ON mydb.mytbl TO 'someuser'@'somehost';
If you specify tbl_name
rather than
db_name.tbl_name
, the statement
applies to tbl_name
in the default
database. An error occurs if there is no default database.
The allowable priv_type
values for a
table are ALTER
,
CREATE VIEW
,
CREATE
,
DELETE
,
DROP
, GRANT
OPTION
, INDEX
,
INSERT
,
SELECT
, SHOW
VIEW
, TRIGGER
, and
UPDATE
.
Table privileges are stored in the
mysql.tables_priv
table.
Column Privileges
Column privileges apply to single columns in a given table. Each privilege to be granted at the column level must be followed by the column or columns, enclosed within parentheses.
GRANT SELECT (col1), INSERT (col1,col2) ON mydb.mytbl TO 'someuser'@'somehost';
The allowable priv_type
values for a
column (that is, when you use a
column_list
clause) are
INSERT
,
SELECT
, and
UPDATE
.
Column privileges are stored in the
mysql.columns_priv
table.
Routine Privileges
The ALTER ROUTINE
,
CREATE ROUTINE
,
EXECUTE
, and
GRANT OPTION
privileges apply to
stored routines (procedures and functions). They can be granted
at the global and database levels. Except for
CREATE ROUTINE
, these privileges
can be granted at the routine level for individual routines.
GRANT CREATE ROUTINE ON mydb.* TO 'someuser'@'somehost'; GRANT EXECUTE ON PROCEDURE mydb.myproc TO 'someuser'@'somehost';
The allowable priv_type
values at the
routine level are ALTER ROUTINE
,
EXECUTE
, and
GRANT OPTION
.
CREATE ROUTINE
is not a
routine-level privilege because you must have this privilege to
create a routine in the first place.
Routine-level privileges are stored in the
mysql.procs_priv
table.
For the global, database, table, and routine levels,
GRANT ALL
assigns only the privileges that exist at the level you are
granting. For example, GRANT ALL ON
is a
database-level statement, so it does not grant any global-only
privileges such as db_name
.*FILE
.
The object_type
clause, if present,
should be specified as TABLE
,
FUNCTION
, or PROCEDURE
when the following object is a table, a stored function, or a
stored procedure.
The privileges for a database, table, column, or routine are
formed additively as the logical OR
of the privileges at each of the privilege levels. For example,
if a user has a global SELECT
privilege, the privilege cannot be denied by an absence of the
privilege at the database, table, or column level. Details of
the privilege-checking procedure are presented in
Section 5.4.5, “Access Control, Stage 2: Request Verification”.
MySQL enables you to grant privileges on databases or tables
that do not exist. For tables, the privileges to be granted must
include the CREATE
privilege.
This behavior is by design, and is intended
to enable the database administrator to prepare user accounts
and privileges for databases or tables that are to be created at
a later time.
MySQL does not automatically revoke any privileges when you drop a database or table. However, if you drop a routine, any routine-level privileges granted for that routine are revoked.
The user
value indicates the MySQL
account to which the GRANT
statement applies. To accommodate granting rights to users from
arbitrary hosts, MySQL supports specifying the
user
value in the form
.
If a user_name
@host_name
user_name
or
host_name
value is legal as an
unquoted identifier, you need not quote it. However, quotes are
necessary to specify a user_name
string containing special characters (such as
“-
”), or a
host_name
string containing special
characters or wildcard characters (such as
“%
”); for example,
'test-user'@'%.com'
. Quote the user name and
host name separately.
You can specify wildcards in the host name. For example,
applies to user_name
@'%.example.com'user_name
for any host in
the example.com
domain, and
applies to user_name
@'192.168.1.%'user_name
for any host in
the 192.168.1
class C subnet.
The simple form user_name
is a
synonym for
.
user_name
@'%'
MySQL does not support wildcards in user
names. To refer to an anonymous user, specify an
account with an empty user name with the
GRANT
statement:
GRANT ALL ON test.* TO ''@'localhost' ...
In this case, any user who connects from the local host with the correct password for the anonymous user will be allowed access, with the privileges associated with the anonymous-user account.
For additional information about user and host values in account names, see Section 5.4.3, “Specifying Account Names”.
To specify quoted values, quote database, table, column, and routine names as identifiers. Quote user names and host names as identifiers or as strings. Quote passwords as strings. For string-quoting and identifier-quoting guidelines, see Section 8.1.1, “Strings”, and Section 8.2, “Schema Object Names”.
The “_
” and
“%
” wildcards are allowed when
specifying database names in
GRANT
statements that grant
privileges at the global or database levels. This means, for
example, that if you want to use a
“_
” character as part of a
database name, you should specify it as
“\_
” in the
GRANT
statement, to prevent the
user from being able to access additional databases matching the
wildcard pattern; for example, GRANT ... ON
`foo\_bar`.* TO ...
.
If you allow anonymous users to connect to the MySQL server,
you should also grant privileges to all local users as
.
Otherwise, the anonymous user account for
user_name
@localhostlocalhost
in the
mysql.user
table (created during MySQL
installation) is used when named users try to log in to the
MySQL server from the local machine. For details, see
Section 5.4.4, “Access Control, Stage 1: Connection Verification”.
You can determine whether the preceding warning applies to you by executing the following query, which lists any anonymous users:
SELECT Host, User FROM mysql.user WHERE User='';
To avoid the problem just described, delete the local anonymous user account using this statement:
DROP USER ''@'localhost';
GRANT
supports host names up to
60 characters long. Database, table, column, and routine names
can be up to 64 characters. User names can be up to 16
characters.
The allowable length for user names cannot be
changed by altering the mysql.user
table.
Attempting to do so results in unpredictable behavior which
may even make it impossible for users to log in to the MySQL
server. You should never alter any of the tables in
the mysql
database in any manner whatsoever
except by means of the procedure described in
Section 4.4.7, “mysql_upgrade — Check Tables for MySQL Upgrade”.
If the NO_AUTO_CREATE_USER
SQL
mode is not enabled and the account named in a
GRANT
statement does not exist in
the mysql.user
table,
GRANT
creates it. If you specify
no IDENTIFIED BY
clause or provide an empty
password, the user has no password. This is very
insecure.
If NO_AUTO_CREATE_USER
is
enabled and the account does not exist,
GRANT
fails and does not create
the account unless the IDENTIFIED BY
clause
is given to provide a nonempty password.
When the IDENTIFIED BY
clause is present and
you have global grant privileges, the password becomes the new
password for the account, even if the account exists and already
has a password.
MySQL Enterprise. The MySQL Enterprise Monitor specifically guards against user accounts with no passwords. To find out more, see http://www.mysql.com/products/enterprise/advisors.html.
REVOKE
does not remove
mysql.user
table entries; you must do that
using DROP USER
or
DELETE
.
Passwords can also be set with the SET
PASSWORD
statement. See
Section 12.4.1.6, “SET PASSWORD
Syntax”.
In the IDENTIFIED BY
clause, the password
should be given as the literal password value. It is unnecessary
to use the PASSWORD()
function as
it is for the SET PASSWORD
statement. For example:
GRANT ... IDENTIFIED BY 'mypass';
If you do not want to send the password in clear text and you
know the hashed value that
PASSWORD()
would return for the
password, you can specify the hashed value preceded by the
keyword PASSWORD
:
GRANT ... IDENTIFIED BY PASSWORD '*6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4';
The WITH
clause is used for several purposes:
To enable a user to grant privileges to other users
To specify resource limits for a user
To specify whether and how a user must use secure connections to the server
The WITH GRANT OPTION
clause gives the user
the ability to give to other users any privileges the user has
at the specified privilege level. You should be careful to whom
you give the GRANT OPTION
privilege because two users with different privileges may be
able to combine privileges!
You cannot grant another user a privilege which you yourself do
not have; the GRANT OPTION
privilege enables you to assign only those privileges which you
yourself possess.
Be aware that when you grant a user the
GRANT OPTION
privilege at a
particular privilege level, any privileges the user possesses
(or may be given in the future) at that level can also be
granted by that user to other users. Suppose that you grant a
user the INSERT
privilege on a
database. If you then grant the
SELECT
privilege on the database
and specify WITH GRANT OPTION
, that user can
give to other users not only the
SELECT
privilege, but also
INSERT
. If you then grant the
UPDATE
privilege to the user on
the database, the user can grant
INSERT
,
SELECT
, and
UPDATE
.
For a nonadministrative user, you should not grant the
ALTER
privilege globally or for
the mysql
database. If you do that, the user
can try to subvert the privilege system by renaming tables!
For additional information about security risks associated with particular privileges, see Section 5.4.1, “Privileges Provided by MySQL”.
Several WITH
clause options specify limits on
use of server resources by an account:
The MAX_QUERIES_PER_HOUR
,
count
MAX_UPDATES_PER_HOUR
, and
count
MAX_CONNECTIONS_PER_HOUR
limits restrict
the number of queries, updates, and connections to the
server allowed to this account during any given one-hour
period. (Queries for which results are served from the query
cache do not count against the
count
MAX_QUERIES_PER_HOUR
limit.) If
count
is 0
(the default), this means that there is no limitation for
the account.
The MAX_USER_CONNECTIONS
limit restricts
the maximum number of simultaneous connections to the server
by the account. A nonzero count
count
specifies the limit for the account explicitly. If
count
is 0
(the default), the server determines the number of
simultaneous connections for the account from the global
value of the
max_user_connections
system
variable. If
max_user_connections
is
also zero, there is no limit for the account.
To specify resource limits for an existing user without
affecting existing privileges, use
GRANT USAGE
at
the global level (ON *.*
) and name the limits
to be changed. For example:
GRANT USAGE ON *.* TO ... WITH MAX_QUERIES_PER_HOUR 500 MAX_UPDATES_PER_HOUR 100;
Limits not specified retain their current values.
For more information on restricting access to server resources, see Section 5.5.4, “Setting Account Resource Limits”.
MySQL can check X509 certificate attributes in addition to the
usual authentication that is based on the user name and
password. To specify SSL-related options for a MySQL account,
use the REQUIRE
clause of the
GRANT
statement. (For background
information on the use of SSL with MySQL, see
Section 5.5.6, “Using SSL for Secure Connections”.)
There are a number of different possibilities for limiting connection types for a given account:
REQUIRE NONE
indicates that the account
has no SSL or X509 requirements. This is the default if no
SSL-related REQUIRE
options are
specified. Unencrypted connections are allowed if the user
name and password are valid. However, encrypted connections
can also be used, at the client's option, if the client has
the proper certificate and key files. That is, the client
need not specify any SSL command options, in which case the
connection will be unencrypted. To use an encrypted
connection, the client must specify either the
--ssl-ca
option, or all
three of the --ssl-ca
,
--ssl-key
, and
--ssl-cert
options.
The REQUIRE SSL
option tells the server
to allow only SSL-encrypted connections for the account.
GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret' REQUIRE SSL;
To connect, the client must specify the
--ssl-ca
option, and may
additionally specify the
--ssl-key
and
--ssl-cert
options.
REQUIRE X509
means that the client must
have a valid certificate but that the exact certificate,
issuer, and subject do not matter. The only requirement is
that it should be possible to verify its signature with one
of the CA certificates.
GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret' REQUIRE X509;
To connect, the client must specify the
--ssl-ca
,
--ssl-key
, and
--ssl-cert
options. This is
also true for ISSUER
and
SUBJECT
because those
REQUIRE
options imply
X509
.
REQUIRE ISSUER
'
places the
restriction on connection attempts that the client must
present a valid X509 certificate issued by CA
issuer
''
. If
the client presents a certificate that is valid but has a
different issuer, the server rejects the connection. Use of
X509 certificates always implies encryption, so the
issuer
'SSL
option is unnecessary in this case.
GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret' REQUIRE ISSUER '/C=FI/ST=Some-State/L=Helsinki/ O=MySQL Finland AB/CN=Tonu Samuel/Email=tonu@example.com';
Note that the
'
value
should be entered as a single string.
issuer
'
REQUIRE SUBJECT
'
places the
restriction on connection attempts that the client must
present a valid X509 certificate containing the subject
subject
'subject
. If the client presents a
certificate that is valid but has a different subject, the
server rejects the connection.
GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret' REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/ O=MySQL demo client certificate/ CN=Tonu Samuel/Email=tonu@example.com';
Note that the
'
value should be entered as a single string.
subject
'
REQUIRE CIPHER
'
is needed to
ensure that ciphers and key lengths of sufficient strength
are used. SSL itself can be weak if old algorithms using
short encryption keys are used. Using this option, you can
ask that a specific cipher method is used to allow a
connection.
cipher
'
GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret' REQUIRE CIPHER 'EDH-RSA-DES-CBC3-SHA';
The SUBJECT
, ISSUER
, and
CIPHER
options can be combined in the
REQUIRE
clause like this:
GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost' IDENTIFIED BY 'goodsecret' REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/ O=MySQL demo client certificate/ CN=Tonu Samuel/Email=tonu@example.com' AND ISSUER '/C=FI/ST=Some-State/L=Helsinki/ O=MySQL Finland AB/CN=Tonu Samuel/Email=tonu@example.com' AND CIPHER 'EDH-RSA-DES-CBC3-SHA';
The order of the options does not matter, but no option can be
specified twice. The AND
keyword is optional
between REQUIRE
options.
If you are using table, column, or routine privileges for even one user, the server examines table, column, and routine privileges for all users and this slows down MySQL a bit. Similarly, if you limit the number of queries, updates, or connections for any users, the server must monitor these values.
The biggest differences between the standard SQL and MySQL
versions of GRANT
are:
In MySQL, privileges are associated with the combination of a host name and user name and not with only a user name.
Standard SQL does not have global or database-level privileges, nor does it support all the privilege types that MySQL supports.
MySQL does not support the standard SQL
UNDER
privilege.
Standard SQL privileges are structured in a hierarchical
manner. If you remove a user, all privileges the user has
been granted are revoked. This is also true in MySQL if you
use DROP USER
. See
Section 12.4.1.2, “DROP USER
Syntax”.
In standard SQL, when you drop a table, all privileges for
the table are revoked. In standard SQL, when you revoke a
privilege, all privileges that were granted based on that
privilege are also revoked. In MySQL, privileges can be
dropped only with explicit
REVOKE
statements or by
manipulating values stored in the MySQL grant tables.
In MySQL, it is possible to have the
INSERT
privilege for only
some of the columns in a table. In this case, you can still
execute INSERT
statements on
the table, provided that you omit those columns for which
you do not have the INSERT
privilege. The omitted columns are set to their implicit
default values if strict SQL mode is not enabled. In strict
mode, the statement is rejected if any of the omitted
columns have no default value. (Standard SQL requires you to
have the INSERT
privilege on
all columns.) Section 5.1.8, “Server SQL Modes”, discusses
strict mode. Section 10.1.4, “Data Type Default Values”, discusses
implicit default values.
User Comments
The normal response from a grant or revoke
statement is "Query OK, 0 rows affected". The
message that zero rows were affected is a common
source of confusion, but should just be ignored by
the user. Trying to revoke grants that were never
granted yields an "ERROR 1147: There is no such
grant defined for user...".
It would be helpful to link the paragraph on the 'WITH GRANT OPTION' to the '--safe-user-create' start option for mysqld.
It may be obvious to experienced users that the GRANT option not only allows to give privileges to existing users, but also to create new users this way. However, it is not intuitive how to restrict this.
Dennis Yu on January 16 2007 9:37am points out
> Privilege SELECT also allows to execute SHOW CREATE TABLE statement.
Indeed, the table showing priv_type meanings, gives:
> SELECT Enables use of SELECT
However, a number of MySQL commands are, effectively, synonyms for SELECT.
DESCRIBE is also a synonym for SELECT, and there may be more such commands.
To display all users Grants (for backup purpose as example) :
mysql -Bse "SELECT CONCAT('SHOW GRANTS FOR \'', user ,'\'@\'', host, '\';') FROM mysql.user" | mysql -Bs | sed 's/$/;/g'
I have recently written a (german) article on how to export the user privileges and import them on another server.
It can be found here:
http://www.lunar.lu/mysql-benutzerrechte-privileges-grants-exportieren/
Regards,
Claude
I thought I'd add that if you script out your backups, you'll want to create a user with the 'LOCK TABLES' privilege for occasions when you're doing complete backups.
E.g.
mysql>GRANT SELECT,LOCK TABLES ON *.* TO backuprobot@'localhost' IDENTIFIED BY 'password'; exit;
# mysqldump -c --routines --triggers --all-databases -u backuprobot -ppassword | gzip > all.sql.gz
To save anyone else a lot of time:
For grant options MAX_QUERIES_PER_HOUR, MAX_UPDATES_PER_HOUR, MAX_CONNECTIONS_PER_HOUR there isn't a way to get the current status (as opposed to the current setting!) e.g. how close is current queries/hour to MAX_QUERIES_PER_HOUR, say for use in a dashboard, or just as a means of determining how close to capacity the current settings are.
To implement a dashboard or equivalent you basically have to redo all the logic on your own. This limits the usefulness of the current grant options.
Add your own comment.