Anyone know why GRANTing ALL TABLE access to 1 schema would fail while succeeding for another schema in the same db? This failure happens when run as the database owner (either from Atlas or from the Neon SQL Editor). This is the code:
GRANT USAGE ON SCHEMA dm TO datamart_pg_reader;
GRANT USAGE ON SCHEMA plus TO datamart_pg_reader;
REVOKE ALL ON SCHEMA public FROM datamart_pg_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA dm TO datamart_pg_reader; -- does not work, even if changed to SELECT, MAINTAIN
GRANT SELECT, MAINTAIN ON ALL TABLES IN SCHEMA plus TO datamart_pg_reader; -- works fine
When run from Neon's SQL Editor, the error "No privileges were granted for table name" appears as a series of popups for each object the GRANT failed for, which seems to be every table in schema dm. Both schema exist (and contain objects) before this code is run. I confirmed the role has the same privileges on both schema (OWNER, USAGE, CREATE) and I don't see any revocation of any privileges for this role.
Looking at the code:
/*
* Restrict the operation to what we can actually grant or revoke, and
* issue a warning if appropriate. (For REVOKE this isn't quite what the
* spec says to do: the spec seems to want a warning only if no privilege
* bits actually change in the ACL. In practice that behavior seems much
* too noisy, as well as inconsistent with the GRANT case.)
*/
this_privileges = privileges & ACL_OPTION_TO_PRIVS(avail_goptions);
if (is_grant)
{
if (this_privileges == 0)
{
if (objtype == OBJECT_COLUMN && colname)
ereport(WARNING,
(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_GRANTED),
errmsg("no privileges were granted for column \"%s\" of relation \"%s\"",
colname, objname)));
else
ereport(WARNING,
(errcode(ERRCODE_WARNING_PRIVILEGE_NOT_GRANTED),
errmsg("no privileges were granted for \"%s\"",
objname)));
}
we learn that you get this error message if you try to grant a privilege that you have no right to grant.
So it seems like the user that runs the GRANT
owns the tables in the one schema, but not in the other schema. To succeed, the current user has to satisfy one of the following conditions:
be a superuser
own the tables on which the privileges are granted
have been granted the privilege WITH GRANT OPTION
Note that owning a database does not imply that you own or have any rights to the objects in the database.