granted role

</para></entry>

</row>

<row>

<entry role="catalog_table_entry"><para role="column_definition">

<structfield>set_option</structfield> <type>bool</type>

</para>

<para>

True if the member can

<link linkend="sql-set-role"><command>SET ROLE</command></link>

to the granted role

</para></entry>

</row>

</tbody>

</tgroup>

</table>

<para>

Does user have privilege for role?

Allowable privilege types are

<literal>MEMBER</literal> and <literal>USAGE</literal>.

<literal>MEMBER</literal>, <literal>USAGE</literal>,

and <literal>SET</literal>.

<literal>MEMBER</literal> denotes direct or indirect membership in

the role(that is, the right to do <command>SET ROLE</command>), while

the rolewithout regard to what specific privileges may be conferred.

<literal>USAGE</literal> denotes whether the privileges of the role

are immediately available without doing <command>SET ROLE</command>.

are immediately available without doing <command>SET ROLE</command>,

while <literal>SET</literal> denotes whether it is possible to change

to the role using the <literal>SET ROLE</literal> command.

This function does not allow the special case of

setting <parameter>user</parameter> to <literal>public</literal>,

because the PUBLIC pseudo-role can never be a member of real roles.

[ GRANTED BY <replaceable class="parameter">role_specification</replaceable> ]

GRANT <replaceable class="parameter">role_name</replaceable> [, ...] TO <replaceable class="parameter">role_specification</replaceable> [, ...]

[ WITH { ADMIN | INHERIT } { OPTION | TRUE | FALSE } ]

[ WITH { ADMIN | INHERIT| SET} { OPTION | TRUE | FALSE } ]

[ GRANTED BY <replaceable class="parameter">role_specification</replaceable> ]

<phrase>where <replaceable class="parameter">role_specification</replaceable> can be:</phrase>

<para>

This variant of the <command>GRANT</command> command grants membership

in a role to one or more other roles. Membership in a role is significant

because it conveys the privileges granted to a role to each of its

members.

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. However, the actualy permisions conferred depend on

the options associated with the grant.

</para>

<para>

The effect of membership in a role can be modified by specifying the

<literal>ADMIN</literal> or <literal>INHERIT</literal> option, each

of which can be set to either <literal>TRUE</literal> or

<literal>FALSE</literal>. The keyword <literal>OPTION</literal> is accepted

as a synonym for <literal>TRUE</literal>, so that

<literal>WITH ADMIN OPTION</literal>

Each of the options described below can be set to either

<literal>TRUE</literal> or <literal>FALSE</literal>. The keyword

<literal>OPTION</literal> is accepted as a synonym for

<literal>TRUE</literal>, so that <literal>WITH ADMIN OPTION</literal>

is a synonym for <literal>WITH ADMIN TRUE</literal>.

</para>

OPTION</literal> on itself. Database superusers can grant or revoke

membership in any role to anyone. Roles having

<literal>CREATEROLE</literal> privilege can grant or revoke membership

in any role that is not a superuser.

in any role that is not a superuser. This option defaults to

<literal>FALSE</literal>.

</para>

<para>

See <link linkend="sql-createrole"><command>CREATE ROLE</command></link>.

</para>

<para>

The <literal>SET</literal> option, if it is set to

<literal>TRUE</literal>, allows the member to change to the granted

role using the

<link linkend="sql-set-role"><command>SET ROLE</command></link>

command. If a role is an indirect member of another role, it can use

<literal>SET ROLE</literal> to change to that role only if there is a

chain of grants each of which has <literal>SET TRUE</literal>.

This option defaults to <literal>TRUE</literal>.

</para>

<para>

If <literal>GRANTED BY</literal> is specified, the grant is recorded as

having been done by the specified role. A user can only attribute a grant

[ GRANTED BY <replaceable class="parameter">role_specification</replaceable> ]

[ CASCADE | RESTRICT ]

REVOKE [ { ADMIN | INHERIT } OPTION FOR ]

REVOKE [ { ADMIN | INHERIT| SET} OPTION FOR ]

<replaceable class="parameter">role_name</replaceable> [, ...] FROM <replaceable class="parameter">role_specification</replaceable> [, ...]

[ GRANTED BY <replaceable class="parameter">role_specification</replaceable> ]

[ CASCADE | RESTRICT ]

<para>

Just as <literal>ADMIN OPTION</literal> can be removed from an existing

role grant, it is also possible to revoke <literal>INHERIT OPTION</literal>.

This is equivalent to setting the value of that option to

<literal>FALSE</literal>.

role grant, it is also possible to revoke <literal>INHERIT OPTION</literal>

or <literal>SET OPTION</literal>.This is equivalent to setting the value

of the corresponding option to<literal>FALSE</literal>.

</para>

</refsect1>

effectively drops all the privileges except for those which the target role

directly possesses or inherits. On the other hand, if the session user role

has been granted memberships <literal>WITH INHERIT FALSE</literal>, the

privileges of the granted roles can't be accessed by default. However, the

privileges of the granted roles can't be accessed by default. However, if

the role was granted <literal>WITH SET TRUE</literal>, the

session user can use <command>SET ROLE</command> to drop the privileges

assigned directly to the session user and instead acquire the privileges

available to the named role.

available to the named role. If the role was granted <literal>WITH INHERIT

FALSE, SET FALSE</literal> then the privileges of that role cannot be

exercised either with or without <literal>SET ROLE</literal>.

</para>

<para>

In particular, when a superuser chooses to <command>SET ROLE</command> to a

Note that when a superuser chooses to <command>SET ROLE</command> to a

non-superuser role, they lose their superuser privileges.

</para>

<para>

The members of a group role can use the privileges of the role in two

ways. First, every member of a group can explicitly do

ways. First, member roles that have been granted membership with the

<literal>SET</literal> option can do

<link linkend="sql-set-role"><command>SET ROLE</command></link> to

temporarily <quote>become</quote> the group role. In this state, the

database session has access to the privileges of the group role rather

CREATE ROLE joe LOGIN;

CREATE ROLE admin;

CREATE ROLE wheel;

CREATE ROLE island;

GRANT admin TO joe WITH INHERIT TRUE;

GRANT wheel TO admin WITH INHERIT FALSE;

GRANT island TO joe WITH INHERIT TRUE, SET FALSE;

</programlisting>

Immediately after connecting as role <literal>joe</literal>, a database

session will have use of privileges granted directly to <literal>joe</literal>

plus any privileges granted to <literal>admin</literal>, because <literal>joe</literal>

<quote>inherits</quote> <literal>admin</literal>'s privileges. However, privileges

plus any privileges granted to <literal>admin</literal> and

<literal>island</literal>, because <literal>joe</literal>

<quote>inherits</quote> those privileges. However, privileges

granted to <literal>wheel</literal> are not available, because even though

<literal>joe</literal> is indirectly a member of <literal>wheel</literal>, the

membership is via <literal>admin</literal> which was granted using

SET ROLE admin;

</programlisting>

the session would have use of only those privileges granted to

<literal>admin</literal>, and not those granted to <literal>joe</literal>. After:

<literal>admin</literal>, and not those granted to <literal>joe</literal> or

<literal>island</literal>. After:

<programlisting>

SET ROLE wheel;

</programlisting>

<note>

<para>

The <command>SET ROLE</command> command always allows selecting any role

that the original login role is directly or indirectly a member of.

that the original login role is directly or indirectly a member of,

provided that there is a chain of membership grants each of which has

<literal>SET TRUE</literal> (which is the default).

Thus, in the above example, it is not necessary to become

<literal>admin</literal> before becoming <literal>wheel</literal>.

On the other hand, it is not possible to become <literal>island</literal>

at all; <literal>joe</literal> can only access those privileges via

inheritance.

</para>

</note>

objname);

}

check_is_member_of_role(GetUserId(),new_ownerId);

check_can_set_role(GetUserId(),new_ownerId);

if (OidIsValid(namespaceId))

(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),

errmsg("permission denied to create database")));

check_is_member_of_role(GetUserId(),datdba);

check_can_set_role(GetUserId(),datdba);

dbname);

check_is_member_of_role(GetUserId(),newOwnerId);

check_can_set_role(GetUserId(),newOwnerId);

NameStr(form->srvname));

check_is_member_of_role(GetUserId(),newOwnerId);

check_can_set_role(GetUserId(),newOwnerId);

aclresult=object_aclcheck(ForeignDataWrapperRelationId,form->srvfdw,newOwnerId,ACL_USAGE);

NameStr(form->pubname));

check_is_member_of_role(GetUserId(),newOwnerId);

check_can_set_role(GetUserId(),newOwnerId);

aclresult=object_aclcheck(DatabaseRelationId,MyDatabaseId,newOwnerId,ACL_CREATE);