On Wed, Jan 02, 2013 at 05:35:13PM +0100, Kohei KaiGai wrote:
> 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.
Would COPY be covered separately? How about TRUNCATE?
Also, is there any way to apply this to the catalog, or would that be
too large a restructuring, given how catalog access actually works?
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
In response to
pgsql-hackers by date
|Next:||From: Fabrízio de Royes Mello||Date: 2013-01-02 17:26:42|
|Subject: Re: Minor fix in 'clean' action of 'src/backend/Makefile'|
|Previous:||From: Tom Lane||Date: 2013-01-02 16:44:32|
|Subject: Re: [COMMITTERS] pgsql: Unify some tar functionality across different parts|