<!--

$Header: /cvsroot/pgsql/doc/src/sgml/ref/grant.sgml,v 1.36 2003/09/20 20:12:05 tgl Exp $

$Header: /cvsroot/pgsql/doc/src/sgml/ref/grant.sgml,v 1.37 2003/10/31 20:00:48 tgl Exp $

PostgreSQL documentation

-->

</para>

<para>

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. (The owner could,

however, choose to revoke some of his own privileges for safety.)

The right to drop an object, or to alter it in any way is

not described by a grantable right; it is inherent in the owner,

and cannot be granted or revoked.

If <literal>WITH GRANT OPTION</literal> is specified, the recipient

of the privilege may in turn grant it to others. By default this

is not allowed. Grant options can only be granted to individual

users, not to groups or <literal>PUBLIC</literal>.

</para>

<para>

If <literal>WITH GRANT OPTION</literal> is specified, the recipient

of the privilege may in turn grant it to others. By default this

is not possible. Grant options can only be granted to individual

users, not groups or <literal>PUBLIC</literal>.

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. (The owner could,

however, choose to revoke some of his own privileges for safety.)

The right to drop an object, or to alter its definition in any way is

not described by a grantable privilege; it is inherent in the owner,

and cannot be granted or revoked. It is not possible for the owner's

grant options to be revoked, either.

</para>

<para>

except when absolutely necessary.

</para>

<para>

If a superuser chooses to issue a <command>GRANT</> or <command>REVOKE</>

command, the command is performed as though it were issued by the

owner of the affected object. In particular, privileges granted via

such a command will appear to have been granted by the object owner.

</para>

<para>

Currently, to grant privileges in <productname>PostgreSQL</productname>

to only a few columns, you must

<!--

$Header: /cvsroot/pgsql/doc/src/sgml/ref/revoke.sgml,v 1.27 2003/08/3117:32:24 petere Exp $

$Header: /cvsroot/pgsql/doc/src/sgml/ref/revoke.sgml,v 1.28 2003/10/3120:00:48 tgl Exp $

PostgreSQL documentation

-->

all users.

</para>

<para>

See the description of the <xref linkend="sql-grant" endterm="sql-grant-title"> command for

the meaning of the privilege types.

</para>

<para>

Note that any particular user will have the sum

of privileges granted directly to him, privileges granted to any group he

directly or via a group will still have it.

</para>

<para>

See the description of the <xref linkend="sql-grant" endterm="sql-grant-title"> command for

the meaning of the privilege types.

</para>

<para>

If <literal>GRANT OPTION FOR</literal> is specified, only the grant

option for the privilege is revoked, not the privilege itself.

the <literal>CASCADE</literal> option so that the privilege is

automatically revoked from user C.

</para>

<para>

If a superuser chooses to issue a <command>GRANT</> or <command>REVOKE</>

command, the command is performed as though it were issued by the

owner of the affected object. Since all privileges ultimately come

from the object owner (possibly indirectly via chains of grant options),

it is possible for a superuser to revoke all privileges, but this may

require use of <literal>CASCADE</literal> as stated above.

</para>

</refsect1>

<refsect1 id="SQL-REVOKE-examples">

{ RESTRICT | CASCADE }

</synopsis>

One of <literal>RESTRICT</literal> or <literal>CASCADE</literal>

is required.

is required according to the standard, but <productname>PostgreSQL</>

assumes <literal>RESTRICT</literal> by default.

</para>

</refsect1>