GRANT on unknown objects need to be rejected about crate HOT 7 OPEN

Just by looking at the behaviours, the objects seem to be not analyzed. There will be more variations around this but I would presume a single fix will address all.

from crate.

I am pretty sure at least for schemas this is intentional, as they are not explicitly created and therefore a user would need to have access to a schema before the first object within it exists.

(Personally I'd prefer for schemas to also be explicitly created)

from crate.

I don't have a clear opinion if this is a bug or a desired behavior.

A bit related, need to test, what happens if you attempt to restore users/roles & their privileges to a new cluster, if the tables/views/schemas are not still there? Maybe it can be handy for such cases to prepare the users/roles & privileges (manually, or with saved statements) before the DB objects are created. Additionally, agreeing with @proddata, since currently we don't have empty schemas, (always need to have the 1st table created within them, and we dont' have a DROP SCHEMA stmt), seems valid to be able to assign privileges to a schema that doesn't exist.

On the other, hand it is weird to select from sys.privileges and see privs for object not existing on the cluster.

from crate.

I am pretty sure at least for schemas this is intentional, as they are not explicitly created and therefore a user would need to have access to a schema before the first object within it exists.

(Personally I'd prefer for schemas to also be explicitly created)

I'm guessing that after: #11939, we can consider implementing the explicit creation/dropping of schemas.

from crate.

After discussion we decided to treat this as an improvement, rather than a bug fix.

from crate.

Some extra info, currently you can restore USERMANAGEMENT, and the privileges are there even though the objects are not:

cr> RESTORE SNAPSHOT repo.snap1 USERMANAGEMENT;
RESTORE OK, 1 row affected  (0.052 sec)
cr> select * from sys.privileges;
+-------+---------+---------+-------+-------+------+
| class | grantee | grantor | ident | state | type |
+-------+---------+---------+-------+-------+------+
| TABLE | matriv  | crate   | doc.t | GRANT | DML  |
+-------+---------+---------+-------+-------+------+
SELECT 1 row in set (0.003 sec)
cr> select * from t;
RelationUnknown[Relation 't' unknown]

If we go ahead to implement throw errors when trying to grant privs on non-existing objects, this will contradict with the restore privs behavior.

from crate.

I would maintain the current behavior until we decide to explicitly create schemas. Once we do, we can more closely link privileges to objects and potentially drop privileges if the associated object no longer exists.

from crate.