[ https://issues.jboss.org/browse/TEIID-5798?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5798: --------------------------------------- That is correct - and the code currently doesn't support that either given the way we flatten grants. Note that it's not the only direction. Pg for example separates the notion of access control from row-based security policy: https://www.postgresql.org/docs/9.5/sql-createpolicy.html More concrete examples of what this could look like: {code} GRANT INSERT,UPDATE,DELETE ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" CONDITION 'UserDefinedProducts_SRC.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36) )' TO odata; GRANT SELECT ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" TO odata; {code} - fairly consistent with our grammar, but not consistent with the current code. Single statement: {code} GRANT SELECT,INSERT,UPDATE,DELETE ON TABLE "my_nutri_diary.UserDefinedProducts_SRC" CONDITION 'UserDefinedProducts_SRC.fkProfile in (SELECT Account.idProfile FROM Account WHERE Account.uuidUser = LEFT(user(), 36) )' FOR INSERT,UPDATE,DELETE TO odata; {code} - smallest change. supports the enhancement requested, but not very powerful Separate GRANT / Policy: see https://www.postgresql.org/docs/9.5/sql-createpolicy.html - it would quite a bit of work to match that behavior / syntax Actually our whole model for dealing with things like conditions and masks are currently very fragile. They are assumed to be applied across the entire permission/grant. For example if you do: GRANT SELECT,INSERT ... CONDITION '...' Then do: REVOKE INSERT ... CONDITION You retain the select permission, but the condition is gone entirely. Introducing multi-statement handling definitely changes the semantics - such that if anyone is currently using multiple grants / revokes per resource, it would be a breaking change. -- This message was sent by Atlassian Jira (v7.13.8#713008)