Re: API change advice: Passing plan invalidation info from the rewriter into the planner?
От | Robert Haas |
---|---|
Тема | Re: API change advice: Passing plan invalidation info from the rewriter into the planner? |
Дата | |
Msg-id | CA+Tgmob2iAHEn5KeFwCd6AfXSc1bGQ7ivY2pzS9ypP0bTXPoUQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: API change advice: Passing plan invalidation info from the rewriter into the planner? (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
On Tue, Jun 24, 2014 at 10:30 AM, Alvaro Herrera <alvherre@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
В списке pgsql-hackers по дате отправления: