If this clause is not specified, it defaults to true if the member role is set to INHERIT and to false if the member role is set to NOINHERIT. If set to FALSE, the member does not inherit the privileges of the granted role. That is, it can automatically use whatever database privileges have been granted to that role. The INHERIT option, if it is set to TRUE, causes the member to inherit the privileges of the granted role. Database superusers can grant or revoke membership in any role to anyone. A role is not considered to hold WITH ADMIN OPTION on itself. Without the admin option, ordinary users cannot do that. The ADMIN option allows the member to in turn grant membership in the role to others, and revoke membership in the role as well. The keyword OPTION is accepted as a synonym for TRUE, so that WITH ADMIN OPTION is a synonym for WITH ADMIN TRUE. However, the actual permissions conferred depend on the options associated with the grant.Įach of the options described below can be set to either TRUE or FALSE. Membership in a role is significant because it potentially allows access to the privileges granted to a role to each of its members, and potentially also the ability to make changes to the role itself. This variant of the GRANT command grants membership in a role to one or more other roles. ALL FUNCTIONS also affects aggregate and window functions, but not procedures, again just like the specific-object GRANT command.
ALL TABLES also affects views and foreign tables, just like the specific-object GRANT command.
This functionality is currently supported only for tables, sequences, functions, and procedures. There is also an option to grant privileges on all objects of the same type within one or more schemas. Alternatively, use ROUTINE to refer to a function, aggregate function, window function, or procedure regardless of its precise type. The FUNCTION syntax works for plain functions, aggregate functions, and window functions, but not for procedures use PROCEDURE for those. The PRIVILEGES key word is optional in PostgreSQL, though it is required by strict SQL. Grant all of the privileges available for the object's type. Specific types of privileges, as defined in Section 5.7. (However, a similar effect can be obtained by granting or revoking membership in the role that owns the object see below.) The owner implicitly has all grant options for the object, too. The right to drop an object, or to alter its definition in any way, is not treated as a grantable privilege it is inherent in the owner, and cannot be granted or revoked. (The owner could, however, choose to revoke some of their own privileges for safety.) There is no need to grant privileges to the owner of an object (usually the user that created it), as the owner has all privileges by default. This clause is currently present in this form only for SQL compatibility. If GRANTED BY is specified, the specified grantor must be the current user. Grant options cannot be granted to PUBLIC. Without a grant option, the recipient cannot do that. If WITH GRANT OPTION is specified, the recipient of the privilege can in turn grant it to others. Any particular role will have the sum of privileges granted directly to it, privileges granted to any role it is presently a member of, and privileges granted to PUBLIC. PUBLIC can be thought of as an implicitly defined group that always includes all roles. The key word PUBLIC indicates that the privileges are to be granted to all roles, including those that might be created later. These privileges are added to those already granted, if any. This variant of the GRANT command gives specific privileges on a database object to one or more roles.
0 kommentar(er)
