From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | tarest2(at)gmail(dot)com |
Cc: | pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: The synopsis of "ALTER DEFAULT PRIVILEGES" statement is too difficult to understand |
Date: | 2021-02-06 20:48:26 |
Message-ID: | 329137.1612644506@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
PG Doc comments form <noreply(at)postgresql(dot)org> writes:
> The syntax/synopsis of the "ALTER DEFAULT PRIVILEGES" statement on the
> https://www.postgresql.org/docs/13/sql-alterdefaultprivileges.html page can
> be simplified to the below form:
> [ factor out privileges and object type ]
Hmm. I can't get too excited about doing that unless we refactor
the GRANT and REVOKE synopses similarly. The factorization seems
a little weird too --- the sub-production is not just privileges,
but privileges and target object type (or in GRANT/REVOKE, it'd
be specific target object(s)). Maybe that's okay, but I'm not 100%
sold on this way being any clearer.
Maybe it'd help to split the GRANT and REVOKE cases completely,
along the lines of
ALTER DEFAULT PRIVILEGES
[ FOR { ROLE | USER } target_role [, ...] ]
[ IN SCHEMA schema_name [, ...] ]
GRANT privilege_and_object_type
TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]
ALTER DEFAULT PRIVILEGES
[ FOR { ROLE | USER } target_role [, ...] ]
[ IN SCHEMA schema_name [, ...] ]
REVOKE [ GRANT OPTION FOR ] privilege_and_object_type
FROM { [ GROUP ] role_name | PUBLIC } [, ...] [ CASCADE | RESTRICT ]
where privilege_and_object_type is one of:
{ SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
[, ...] | ALL [ PRIVILEGES ] }
ON TABLES
... etc etc ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2021-02-07 01:57:01 | Re: pg_wal_lsn_diff |
Previous Message | Tom Lane | 2021-02-06 16:57:56 | Re: pg_wal_lsn_diff |