Re: Review of Row Level Security

2012/12/31 Simon Riggs <simon(at)2ndquadrant(dot)com>:
> On 23 December 2012 18:49, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
>> Anyway, hope you can make call on 28th so we can discuss this and
>> agree a way forwards you're happy with.
>
> Stephen, KaiGai and myself met by phone on 28th to discuss.
>
> 1. The actual default is not that important to any of us. We could go
> either way, or have no default at all.
>
> 2. What we do want is a declarative way of specifying row security,
> with options to support all use cases discussed/requested on list. We
> shouldn't
> support just one of those use cases and force everybody else to use
> triggers manually for the other cases.
>
> 3. We want to have the possibility of multiple row security
> expressions, defined for different privilege types (SELECT, UPDATE,
> INSERT, DELETE). (Note that this means you'd be able to specify that
> an update could read a row in one security mode by setting SELECT,
> then update that row to a new security mode by setting a clause on
> UPDATE - hence we refer to those as privileges not commands/events).
> The expressions should be separate so they can be pushed easily into
> query plans (exactly as in the current patch).
>
> Stephen has updated the Wiki with some ideas on how that can be structured
> https://wiki.postgresql.org/wiki/RLS
>
> 4. Supporting multiple expressions may not be possible for 9.3, but if
> not, we want to agree now what the syntax is to make sure we have a
> clear route for future development. If we can agree this quickly we
> increase the chances of KaiGai successfully implementing that.
>
The syntax being discussed were below:

ALTER TABLE <relname> SET ROW SECURITY FOR <privilege> TO (<expression>);
ALTER TABLE <relname> RESET ROW SECURITY FOR <privilege>;

<privilege> can be one of: ALL, SELECT, INSERT, UPDATE, DELETE

The point in development towards v9.3 is, we only support "ALL" but
we can add other command types in the future.
IMO, only "parser" should accept command types except for ALL but
raise an error something like "it is not supported yet" to protect from
syntax conflicts.

Right now, I plan to submit a revised patch with the syntax support
above, and without support for INSERT or NEW of UPDATE checks,
as minimum set of functionality for v9.3.

Please give me some suggestions, if you have different opinion
towards the overall direction, until 15th-Jan.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>