Privileges
See Privileges for what each privilege allows in
full, and how a creation privilege resolves against an object’s parent when
the object doesn’t exist yet.
Grantees
A grantee is a role, or a user or group named by its identity-directory name or its directory ID. A grantee with no leadingROLE/USER/GROUP keyword
takes the kind of the one before it, so TO ROLE a, b names two roles —
but the first grantee in the list always needs its keyword. An unquoted name
is folded to lowercase before it is looked up; quote one that has capitals,
such as TO ROLE "DataEng".
Naming the target
ASECRET or FUNCTION target can be qualified with its namespace and
database, the same as anywhere else: SECRET analytics.api_key,
SECRET db1.analytics.api_key. SCHEMA and NAMESPACE both target a
namespace but aren’t interchangeable: SCHEMA <namespace> takes the
namespace’s complete path, while NAMESPACE <name> [IN <schema>] takes
one unqualified component, resolved under an explicit parent schema or the
session’s current namespace when IN is omitted — NAMESPACE a.b (a
qualified name with no IN) is refused. A MATERIALIZED VIEW is a table
for authorization purposes: the same privileges apply, and granting one
does not reach the non-materialized VIEW beside it.
How a statement is applied
- A statement applies all of its changes or none of them.
- The caller must already hold
OWNERSHIPon the object to change any grant on it. - Granting a privilege a grantee already holds, or revoking one it does not hold, is a no-op.
GRANTrequires the object to exist;REVOKEdoes not, so an entry left on a dropped object can still be removed. A role need not exist beforehand, but aUSERorGROUPname must resolve to exactly one identity in your identity provider — checked only after the caller’sOWNERSHIP— or the statement fails. TheID '<id>'form is not looked up.GRANT ... ON ... FROM ...andREVOKE ... ON ... TO ...are both refused;GRANTalways takesTO,REVOKEalways takesFROM.- Returns one row per privilege and grantee, with status
granted,already_granted,revokedornot_granted.
SQL has no syntax for binding a Secret to a Function; that’s a
registration-time argument to
create_function in the Python SDK. See
Vend a Secret to a Function.SHOW GRANTS
subject_id, subject_name, object and
privilege. ON filters to one target’s own grants; TO filters to one
or more grantees; combine both, or omit both for every grant the caller
can see. ON <target> requires USAGE on that target; a target-less call
requires system USAGE instead, since it can surface grants across the
whole catalog. SHOW ROLE BINDINGS is the counterpart for role
membership rather than object privileges — see
Role membership in SQL.
What to read next
Privileges
The full privilege model, and how creation privileges resolve upward.
Namespace
Creating the schemas these privileges apply to.