> So basically where we are dispatching to the CASCADE guts, first check session user’s DELETE permission and throw the normal permissions error if they can’t delete?
Actually, you also need appropriate SELECT permissions that correspond to the WHERE clause of the DELETE statement.
So this would be both a table-level and column level check? (It seems odd that we could configure a policy whereby we could DELETE an arbitrary row in the table, but not SELECT which one, but I can see that there could be information leakage implications here.)
Other permissions-level things to consider, like RLS, or is this part automatic? Do you happen to know offhand another instance in the code which takes these granular permissions into consideration? Might help bootstrap both the understanding and the implementation of this.
