KaiGai,
* Kohei KaiGai (kaigai@kaigai.gr.jp) wrote:
> 2014-07-09 15:07 GMT+09:00 Stephen Frost <sfrost@snowman.net>:
> > * Kohei KaiGai (kaigai@kaigai.gr.jp) wrote:
> >> What I'd like to implement is adjustment of query like:
> >> SELECT * FROM t1 WHERE (x like '%abc%') AND (quals by built-in RLS)
> >> AND (quals by extension-1) AND ... AND (quals by extension-N);
> >> I never mind even if qualifiers in the second block are connected with OR'd
> >> manner, however, I want RLS infrastructure to accept additional security
> >> models provided by extensions.
> >
> > Would having a table-level 'AND'-vs-'OR' modifier for the RLS policies
> > on that table be sufficient for what you're looking for? That seems a
> > simple enough addition which would still allow more complex groups to be
> > developed later on...
> >
> Probably, things I'm considering is more simple.
> If a table has multiple built-in RLS policies, its expression node will be
> represented as a BoolExpr with OR_EXPR and every policies are linked
> to its args field, isn't it? We assume the built-in RLS model merges
> multiple policies by OR manner.
> In case when an extension want to apply additional security model on
> top of RLS infrastructure, a straightforward way is to add its own rules
> in addition to the built-in rules. If extension can get control to modify
> the above expression node and RLS infrastructure works well on the
> modified expression node, I think it's sufficient to implement multiple
> security models on the RLS infrastructure.
Another way would be to have a single RLS policy which extensions can
modify, sure. That was actually along the lines of the originally
proposed patch.. That approach would work if we OR'd multiple policies
together too, provided the user took care to only have one policy
implemented.. Not sure how easy that would be to work with for
extension authors though.
Thanks,
Stephen
