On Tue, Jun 24, 2014 at 10:30 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Robert Haas wrote: >> > Right, if we were to support multiple policies on a given table then we >> > would have to support adding and removing them individually, as well as >> > specify when they are to be applied- and what if that "when" overlaps? >> > Do we apply both and only a row which passed them all gets sent to the >> > user? Essentially we'd be defining the RLS policies to be AND'd >> > together, right? Would we want to support both AND-based and OR-based, >> > and allow users to pick what set of conditionals they want applied to >> > their various overlapping RLS policies? >> >> AND is not a sensible policy; it would need to be OR. If you grant >> someone access to two different subsets of the rows in a table, it >> stands to reason that they will expect to have access to all of the >> rows that are in at least one of those subsets. > > I haven't been following this thread, but this bit caught my attention. > I'm not sure I agree that OR is always the right policy either. > There is a case for a policy that says "forbid these rows to these guys, > even if they have read permissions from elsewhere". If OR is the only > way to mix multiple policies there might not be a way to implement this. > So ISTM each policy must be able to indicate what to do -- sort of how > PAM config files allow you to specify "required", "optional" and so > forth for each module.
Hmm. Well, that could be useful, but I'm not sure I'd view it as something we absolutely have to have... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
