I've been trying to learn more about the row-security policies but coming up short in my searches. Was there any consideration to allowing access to both old and new row tuples in a POLICY ... CHECK expression? This idiom I've seen in the lower level rule and trigger systems seems like it would allow for much more powerful row-security policies. The simple illustrations of row-security policy always seem to consider an 'owner' field in the tuple compared to current_user. If you could consult both old and new values, you could generalize to storing application ACLs in rows and using those ACLs to decide row access while also ensuring that ACLs cannot be changed in ways inconsistent with the privilege level of the current user. For example, if the current user is in the old ACL value, allow them to modify the ACL otherwise require that the new ACL value be equal to the old ACL value. This would allow a user to be given write access to some columns while restricting others, but on a row-by-row basis. Right now, as I understand it, you can only compare the old values to session state in the WITH condition and new values to the session state in the CHECK condition, but never consider old and new values simultaneously. This excludes a wide and useful gray area between no trust and full trust to amend row content. Karl -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
