Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 27 May 2015 at 02:42, Stephen Frost <sfr...@snowman.net> wrote: > > Now, looking at the code, I'm actually failing to see a case where we > > use the RowSecurityPolicy->policy_name.. Perhaps *that's* what we > > should be looking to remove? > > If we add support for restrictive policies, it would be possible, and > I think desirable, to report on which policy was violated. For that, > having the policy name would be handy. We might also arguably decide > to enforce restrictive RLS policies in name order, like check > constraints. Of course none of that means it must be kept now, but it > feels like a useful field to keep nonetheless.
I agree that it could be useful, but we really shouldn't have fields in
the current code base which are "just in case".. The one exception
which comes to mind is if we should keep it for use by extensions.
Those operate on an independent cycle from our major releases and would
likely find having the name field useful.
One thing which now occurs to me, however, is that, while the current
coding is fine, using InvalidOid as an indicator for the default-deny
policy, in general, does fall over when we consider policies added by
extensions. Those policies are necessairly going to need to put
InvalidOid into that field, unless they acquire an OID somehow
themselves (it doesn't seem reasonable to make that a requirement,
though I suppose we could..), and, therefore, perhaps we should add a
boolean field which indicates which is the defaultDeny policy anyway and
not use that field for that purpose.
Thoughts?
Thanks!
Stephen
signature.asc
Description: Digital signature
