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+TgmobZTJNDisC8ikUWDjja+fnxgu-9zeTMDe-BEaFG6u8_2Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: API change advice: Passing plan invalidation info from the rewriter into the planner? (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: API change advice: Passing plan invalidation info from
the rewriter into the planner?
Re: API change advice: Passing plan invalidation info from the rewriter into the planner? |
Список | pgsql-hackers |
On Fri, Jun 13, 2014 at 3:11 AM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > Yeah, I was thinking something like this could work, but I would go > further. Suppose you had separate GRANTable privileges for direct > access to individual tables, bypassing RLS, e.g. > > GRANT DIRECT SELECT|INSERT|UPDATE|DELETE ON table_name TO role_name So, is this one new privilege (DIRECT) or four separate new privileges that are variants of the existing privileges (DIRECT SELECT, DIRECT INSERT, DIRECT UPDATE, DIRECT DELETE)? > Actually, given the fact that the majority of users won't be using > RLS, I would be tempted to invert the above logic and have the new > privilege be for LIMITED access (via RLS quals). So a user granted the > normal SELECT privilege would be able to bypass RLS, but a user only > granted LIMITED SELECT wouldn't. Well, for the people who are not using RLS, there's no difference anyway. I think it matters more what users of RLS will expect from a command like GRANT SELECT ... and I'm guessing they'll prefer that RLS always apply unless they very specifically grant the right for RLS to not apply. I might be wrong, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: