Re: API change advice: Passing plan invalidation info from the rewriter into the planner?

Поиск
Список
Период
Сортировка
От Brightwell, Adam
Тема Re: API change advice: Passing plan invalidation info from the rewriter into the planner?
Дата
Msg-id CAKRt6CTcLGEjcfb5Ahg2nmjNBTZL1kHC-rEx5tX30WTZzwdftg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: API change advice: Passing plan invalidation info from the rewriter into the planner?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hey Tom,
 
Hm ... I'm not following why we'd need a special case for superusers and
not anyone else?  Seems like any useful RLS scheme is going to require
more privilege levels than just superuser and not-superuser.

As it stands right now, superuser is the only case where RLS policies should not be applied/completely ignored.  I suppose it is possible to create RLS policies that are related to other privilege levels, but those would still need to be applied despite user id, excepting superuser.  I'll defer to Stephen or Craig on the usefulness of this scheme.

Could we put the "if superuser then ok" test into the RLS condition test
and thereby not need more than one plan at all?

As I understand it, the application of RLS policies occurs in the rewriter.  Therefore, when switching back and forth between superuser and not-superuser the query must be rewritten, which would ultimately result in the need for a new plan correct?  If that is the case, then I am not sure how one plan is possible.  However, again, I'll have to defer to Stephen or Craig on this one.

Thanks,
Adam

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: Re: Why is it "JSQuery"?
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Why is it "JSQuery"?