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
