Grants and Revoke Priv in Greenplum

GRANT { {SELECT | INSERT | UPDATE | DELETE | REFERENCES |

TRIGGER} [,...] | ALL [PRIVILEGES] }

ON [TABLE] tablename [, ...]

TO {rolename | PUBLIC} [, ...] [WITH GRANT OPTION]

GRANT { {USAGE | SELECT | UPDATE} [,...] | ALL [PRIVILEGES] }

ON SEQUENCE sequencename [, ...]

TO { rolename | PUBLIC } [, ...] [WITH GRANT OPTION]

GRANT { {CREATE | CONNECT | TEMPORARY | TEMP} [,...] | ALL

[PRIVILEGES] }

ON DATABASE dbname [, ...]

TO {rolename | PUBLIC} [, ...] [WITH GRANT OPTION]

GRANT { EXECUTE | ALL [PRIVILEGES] }

ON FUNCTION funcname ( [ [argmode] [argname] argtype [, ...]

] ) [, ...]

TO {rolename | PUBLIC} [, ...] [WITH GRANT OPTION]

GRANT { USAGE | ALL [PRIVILEGES] }

ON LANGUAGE langname [, ...]

TO {rolename | PUBLIC} [, ...] [WITH GRANT OPTION]

GRANT { {CREATE | USAGE} [,...] | ALL [PRIVILEGES] }

ON SCHEMA schemaname [, ...]

TO {rolename | PUBLIC} [, ...] [WITH GRANT OPTION]

GRANT { CREATE | ALL [PRIVILEGES] }

ON TABLESPACE tablespacename [, ...]

TO {rolename | PUBLIC} [, ...] [WITH GRANT OPTION]

GRANT parent_role [, ...]

TO member_role [, ...] [WITH ADMIN OPTION]

GRANT { SELECT | INSERT | ALL [PRIVILEGES] }

ON PROTOCOL protocolname

TO username

Granting permission on a table does not automatically extend permissions to any sequences used by the table, including sequences tied to SERIAL columns. Permissions on a sequence must be set separately. Greenplum Database does not support granting or revoking privileges for individual columns of a table. One possible workaround is to create a view having just the desired columns and then grant privileges to that view.

Use psql’s \z meta-command to obtain information about existing privileges for an object.

REVOKE [GRANT OPTION FOR] { {SELECT | INSERT | UPDATE | DELETE

| REFERENCES | TRIGGER} [,...] | ALL [PRIVILEGES] }

ON [TABLE] tablename [, ...]

FROM {rolename | PUBLIC} [, ...]

[CASCADE | RESTRICT]

REVOKE [GRANT OPTION FOR] { {USAGE | SELECT | UPDATE} [,...]

| ALL [PRIVILEGES] }

ON SEQUENCE sequencename [, ...]

FROM { rolename | PUBLIC } [, ...]

[CASCADE | RESTRICT]

REVOKE [GRANT OPTION FOR] { {CREATE | CONNECT

| TEMPORARY | TEMP} [,...] | ALL [PRIVILEGES] }

ON DATABASE dbname [, ...]

FROM {rolename | PUBLIC} [, ...]

[CASCADE | RESTRICT]

REVOKE [GRANT OPTION FOR] {EXECUTE | ALL [PRIVILEGES]}

ON FUNCTION funcname ( [[argmode] [argname] argtype

[, ...]] ) [, ...]

FROM {rolename | PUBLIC} [, ...]

[CASCADE | RESTRICT]

REVOKE [GRANT OPTION FOR] {USAGE | ALL [PRIVILEGES]}

ON LANGUAGE langname [, ...]

FROM {rolename | PUBLIC} [, ...]

[ CASCADE | RESTRICT ]

REVOKE [GRANT OPTION FOR] { {CREATE | USAGE} [,...]

| ALL [PRIVILEGES] }

ON SCHEMA schemaname [, ...]

FROM {rolename | PUBLIC} [, ...]

[CASCADE | RESTRICT]

REVOKE [GRANT OPTION FOR] { CREATE | ALL [PRIVILEGES] }

ON TABLESPACE tablespacename [, ...]

FROM { rolename | PUBLIC } [, ...]

[CASCADE | RESTRICT]

REVOKE [ADMIN OPTION FOR] parent_role [, ...]

FROM member_role [, ...]

[CASCADE | RESTRICT]

Database superusers can access all objects regardless of object privilege settings. One exception to this rule is view objects. Access to tables referenced in the view is

determined by permissions of the view owner not the current user (even if the current user is a superuser).

If a superuser chooses to issue a GRANT or 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. For role membership, the membership appears to have been granted by the

containing role itself.

GRANT and REVOKE can also be done by a role that is not the owner of the affected object, but is a member of the role that owns the object, or is a member of a role that

holds privileges WITH GRANT OPTION on the object. In this case the privileges will be recorded as having been granted by the role that actually owns the object or holds the

privileges WITH GRANT OPTION.