I feel that the fundamental question here is about the semantics of "row" in row security. The core question is whether UPDATE has a different semantics with respect to row identity and security context than a sequence of DELETE, INSERT. At the moment, the documented solution feels like "tuple security" and supports an idea of security context encoded into a tuple such that a policy condition can decide whether its context and data configuration is consistent with the session context. This makes sense in a pure relational calculus, but ignores the practical deviation of SQL where there are mutable records. I am hoping for "record security" that supports an idea of security context encoded into a record such that the context in the existing record can constrain how the update of the record is formed. This includes policies that might differentiate updates to key versus non-key fields in the record, deciding in application terms whether the record has an identity and context that carries forward through the UPDATE or whether it is merely sugar for a DELETE followed by INSERT. Ideally, I'd be able to write a policy that has conditions for each category of operation: POLICY FOR SELECT WITH expr1 POLICY FOR INSERT WITH expr2 POLICY FOR DELETE WITH expr3 POLICY FOR UPDATE WITH expr4 where expr1 would always be used to decide whether the current tuple is visible to the query engine, expr2 would always be used to validate new rows, expr3 would always be used to authorize row deletion, and expr4 would be able to authorize row replacement using NEW and OLD value comparisons. An actual SQL UPDATE for a row visible according to expr1 could be authorized if expr4 allows it *or* if expr3 and expr2 would allow a DELETE followed by INSERT. Where this becomes interesting is when a session context with insufficient privilege to do the DELETE and INSERT sequence is still allowed to do the UPDATE because their request fits the narrower confines of the expr4 policy. Karl -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
