Re: [v9.4] row level security

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [v9.4] row level security
Дата
Msg-id 3942.1378310299@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [v9.4] row level security  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Список pgsql-hackers
Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
> 2013/9/4 Tom Lane <tgl@sss.pgh.pa.us>:
>> And for insert/update/delete, we do what exactly?

> Regarding to update/delete, this patch also enhanced to allow update or
> delete mechanism allows to take a sub-query on top of the table scan plan.

> So, its explain output shows as follows:

> postgres=> EXPLAIN (costs off) UPDATE customer SET email = 'alice@example.com';
>                     QUERY PLAN
> --------------------------------------------------
>  Update on customer
>    ->  Subquery Scan on customer
>          ->  Seq Scan on customer customer_1
>                Filter: ("current_user"() = uname)

> You can see this update has Subquery plan instead of regular relation scan.

Really?  That wasn't apparent from reading the patch.  (Have I mentioned
it's desperately underdocumented?  Aside from needing a lot more in-code
comments than it's got, it would benefit from having an overview section
added to optimizer/README explaining stuff at the level of this
discussion.)

I'm a bit surprised that setrefs.c doesn't eliminate the Subquery Scan as
being a no-op, given that no quals end up getting applied at that level.
You might look into why not, since if that plan node were eliminated at
the end, it'd fix any efficiency complaints about this approach.
        regards, tom lane



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

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: Re: [v9.4] row level security
Следующее
От: Kevin Grittner
Дата:
Сообщение: Eliminating pg_catalog.pg_rewrite.ev_attr