Object Privileges
The privilege granted depends on the type of object it affects: TABLE, DATABASE, PROCEDURE, DBEVENT, or SEQUENCE.
TABLE Privileges
Table privileges control access to tables and views. By default, only the owner of the table has privileges for the table. To enable others to access the table, the owner must grant privileges to specific authorization IDs or to public. Table privileges must be granted explicitly.
Valid table privileges are:
SELECT
Allows grantee to select rows from the table.
INSERT
Allows grantee to add rows to the table.
UPDATE
Allows grantee to change existing rows. To limit the columns that the grantee can change, specify a list of columns to allow or a list of columns to exclude.
To grant the privilege for specific columns, use the following syntax after the UPDATE keyword in the GRANT statement:
(column_name {, column_name)
To grant the privilege for all columns except those specified, use the following syntax after the UPDATE keyword in the GRANT statement:
EXCLUDING (column_name {, column_name})
If the column list is omitted, update privilege is granted to all columns of the table or, for views, all updatable columns.
DELETE
Allows grantee to delete rows from the table.
REFERENCES
Allows grantee to create referential constraints that reference the specified tables and columns. For details about referential constraints, see
CREATE TABLE. A list of columns to allow or to exclude can optionally be specified.
To grant the privilege for specific columns except those specified, use the following syntax after the REFERENCES keyword in the GRANT statement:
(column_name {, column_name})
To grant the privilege for all columns except those specified, use the following syntax after the REFERENCES keyword in the GRANT statement:
EXCLUDING (column_name {, column_name})
If the column list is omitted, references privilege is granted to all columns of the table. The references privilege cannot be granted on a view.
COPY_INTO
Allows the grantee to issue the COPY...INTO statement on a table. This privilege can be granted on tables only.
COPY_FROM
Allows the grantee to issue the COPY...FROM statement on a table. This privilege can be granted on tables only.
ALL [PRIVILEGES]
Grants the subset of select, insert, update, delete, and references privileges for which the grantor has GRANT OPTION. For details, see
GRANT ALL PRIVILEGES Option.
When privileges are granted against a table, the date and timestamp of the specified table is updated, and the DBMS Server recreates query plans for repeat queries and database procedures that see the specified table.
TABLE Privileges for Views
The privileges required to enable the owner of a view to grant privileges on the view are as follows:
SELECT
View owner must own all tables and views used in the view definition, or view owner or public must have GRANT OPTION for SELECT for the tables and views used in the view definition.
INSERT
View owner must own all tables and views used in the view definition, or view owner or public must have GRANT OPTION for INSERT for the tables and views used in the view definition.
UPDATE
View owner must own all tables and updatable columns in views used in the view definition, or view owner or public must have GRANT OPTION for UPDATE for the tables and updatable columns in views used in the view definition.
DELETE
View owner must own all tables and views used in the view definition, or view owner or public must have GRANT OPTION for DELETE for the tables and views used in the view definition.
To grant privileges for views the grantor does not own, the grantor must have been granted the specified privilege WITH GRANT OPTION.
DATABASE Privileges
Database privileges control the consumption of computing resources.
To override the default for a database privilege, grant a specific value to PUBLIC. For example, by default, everyone (PUBLIC) has the privilege to create tables. To override the default, grant NOCREATE_TABLE to PUBLIC, and grant the CREATE_TABLE privilege to any user, group, or role that you want to have this privilege. (Users, groups, and roles are referred to collectively as authorization IDs.)
Database privileges do not apply to DBAs in their own databases, nor to security administrators.
The database privileges in effect for a session are determined by the values that were granted to the authorization IDs in effect for the session, according to the following hierarchy:
1. Role
2. User
3. Group
4. Public
For example, if different values for CREATE_TABLE are granted to PUBLIC, and to the user, group, and role that are in effect for a session, the value for the role of the session prevails.
Valid database privileges are as follows:
[NO]ACCESS
Allows the specified authorization IDs to connect to the specified database.
NOACCESS prevents the specified authorization IDs from connecting.
Note: The access bitmask of the iidatabase_info catalog is set only if database utilities are used to change the access rights to the database. Using a GRANT [NO]ACCESS ON DATABASE dbname TO PUBLIC statement does not change the access from global to private or vice versa in iidatabase_info.
[NO]CREATE_PROCEDURE
Allows the specified authorization IDs to create database procedures in the specified database.
NOCREATE_PROCEDURE prevents the specified users, groups, or roles from creating database procedures.
Default: All authorization IDs can create database procedures.
[NO]CREATE_TABLE
Allows the specified authorization IDs to create tables in the specified database.
NOCREATE_TABLE prevents the specified authorization IDs from creating tables.
Default: All authorization IDs can create tables.
[NO]DB_ADMIN
Confers unlimited database privileges for the specified database and the ability to specify effective user (using the -u flag). A session that has the DB_ADMIN privilege does not have all the rights that a DBA has; some utilities can be run only by a DBA. The DBA of a database and users with the SECURITY privilege have the DB_ADMIN privilege by default. For all other users, the default is NODB_ADMIN.
[NO]CONNECT_TIME_LIMIT
Limits the total connect time that a session can consume. The connect time is checked periodically by the DBMS Server and if the limit has been exceeded for a session, it is disconnected, rolling back any open database transactions.
The units are seconds. The maximum connection time limit is 2147483647 seconds, approximately 68 years. The minimum connection time limit is 1 second.
As with other database privileges this can be granted to user, group, role or public, and can only be issued when connected to the iidbdb database.
Default: No limit, that is, a session can remain connected indefinitely.
[NO]IDLE_TIME_LIMIT
Specifies the time that a session can take between issuing statements. The idle time for each session is checked periodically by the DBMS Server, and if a session exceeds its idle time limit it is disconnected, rolling back any open database transactions.
The units are seconds. The maximum idle time limit is 2147483647 seconds, approximately 68 years. The minimum idle time limit is 1 second. Idle_time_limit can be granted to user, group, role or public, and can only be issued when connected to the iidbdb database.
Default: No limit, that is, a session can remain idle indefinitely without being disconnected.
[NO]QUERY_COST_LIMIT
Specifies the maximum cost per query on the database, in terms of disk I/O and CPU usage.
Default: Authorization identifiers are allowed an unlimited cost per query.
[NO]QUERY_CPU_LIMIT
Specifies the maximum CPU usage per query on the database.
Default: Authorization identifiers are allowed unlimited CPU usage per query.
[NO]QUERY_IO_LIMIT
Specifies the maximum estimated number of I/O requests allowed for a single query for the specified authorization IDs when connected to the specified database. Integer must be a non-negative integer (or 0 to specify that no I/O is performed).
NOQUERY_IO_LIMIT grants an unlimited number of I/O requests per query.
Default: NOQUERY_IO_LIMIT
[NO]QUERY_PAGE_LIMIT
Specifies the maximum number of pages per query on the database.
Default: Authorization identifiers are allowed an unlimited number of pages per query.
[ACTUAL | ESTIMATED] [NO]QUERY_ROW_LIMIT n
Specifies the maximum ACTUAL or ESTIMATED number of rows returned by a single query for the specified authorization IDs when connected to the specified database. Integer must be a positive number (or 0 to specify that no rows are returned). ESTIMATED is the default and does not need to be specified. ACTUAL and ESTIMATED are mutually exclusive.
NOQUERY_ROW_LIMIT allows a single query to return an unlimited number of rows.
Default: NOQUERY_ROW_LIMIT
[NO]UPDATE_SYSCAT
Allows the specified authorization IDs to update system catalogs when working in a session connected to the iidbdb.
[NO]READONLY
Controls the access mode for the database. READONLY disallows insert, update, delete, truncate, copy, and DDL operations and returns an SQLSTATE of 25000 (invalid session state). Temporary tables are the exception and are always writable. When a READONLY session is begun, it registers itself with the logging system and is allowed to proceed even when a ckpdb is pending against the database for the session. Use it for applications that can be read only most of the time.
[NO]SELECT_SYSCAT
Allows a session to query system catalogs to determine schema information. When connected to the master database (iidbdb), this includes the master database catalogs such as iiuser and iidatabase. SELECT_SYSCAT can be granted to user, group, role or public, and can only be issued when connected to the iidbdb database.
This privilege restricts user queries against the core DBMS catalogs containing schema information, such as iirelation and iiattribute. Standard system catalogs such as iitables can still be queried.
[NO]SESSION_PRIORITY
Note: Whether this privilege has an effect depends on the operating system.
Determines whether a session is allowed to change its priority, and if so, its initial and highest priority.
If NOSESSION_PRIORITY (the default) is specified, users can not alter their session priority.
If SESSION_PRIORITY is specified, users can alter their session priority, up to the limit determined by the privilege.
[NO]TIMEOUT_ABORT
Allows the specified authorization IDs to issue the SET JOINOP TIMEOUTABORT statement.
NOTIMEOUT_ABORT prevents the specified users, groups, or roles from issuing the SET JOINOP TIMEOUTABORT statement.
Default: Everyone can issue the SET JOINOP TIMEOUTABORT statement.
Note: The restrictions set by QUERY_COST_LIMIT, QUERY_CPU_LIMIT, QUERY_IO_LIMIT, QUERY_PAGE_LIMIT, and QUERY_ROW_LIMIT are enforced based on estimates from the DBMS query optimizer. If the optimizer predicts that a query consumes more I/Os than allowed by the session, the query is aborted prior to execution. The accuracy of the optimizer's estimates can be impeded by out-of-date or insufficient statistics about the contents of tables. For QUERY_ROW_LIMIT, actuals rather than estimates can be used.
PROCEDURE Privileges
The EXECUTE privilege allows the grantee to execute the specified database procedures. To grant the EXECUTE privilege on database procedures, the owner of the procedure must have GRANT OPTION for all the privileges required to execute the procedure. To grant the EXECUTE privilege on database procedures that the grantor does not own, the grantor must have EXECUTE privilege WITH GRANT OPTION for the database procedure.
DBEVENT Privileges
Database event privileges are as follows:
RAISE
Allows the specified authorization IDs to raise the database event (using the RAISE DBEVENT statement)
REGISTER
Allows the specified authorization IDs to register to receive a specified database event (using the REGISTER DBEVENT statement)
SEQUENCE Privileges
The sequence privilege is as follows:
NEXT
Allows the grantee to execute the NEXT VALUE and CURRENT VALUE functions on the specified sequences. To grant the NEXT privilege on sequences, the grantor must either own the sequence or have NEXT privilege WITH GRANT OPTION for the sequence.