Re: [v9.3] Row-Level Security

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [v9.3] Row-Level Security
Дата
Msg-id 13017.1340744395@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [v9.3] Row-Level Security  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Ответы Re: [v9.3] Row-Level Security  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Список pgsql-hackers
Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
> 2012/6/26 Robert Haas <robertmhaas@gmail.com>:
>> I think you're missing the point. �Everyone who has commented on this
>> issue is in favor of having some check that causes the RLS predicate
>> *not to get added in the first place*.

> Here is a simple idea to avoid the second problematic scenario; that
> assign 0 as cost of has_superuser_privilege().

I am not sure which part of "this isn't safe" isn't getting through to
you.  Aside from the scenarios Robert mentioned, consider the
possibility that f_malicious() is marked immutable, so that the planner
is likely to call it (to replace the call with its value) before it will
ever think about whether has_superuser_privilege should be called first.

Please just do what everybody is asking for, and create a bypass that
does not require fragile, easily-broken-by-future-changes assumptions
about what the planner will do with a WHERE clause.
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: pg_terminate_backend for same-role
Следующее
От: Robert Haas
Дата:
Сообщение: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap