Skip site navigation (1) Skip section navigation (2)

Re: Review of Row Level Security

From: David Fetter <david(at)fetter(dot)org>
To: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,Stephen Frost <sfrost(at)snowman(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Robert Haas <robertmhaas(at)gmail(dot)com>,Kevin Grittner <kgrittn(at)mail(dot)com>
Subject: Re: Review of Row Level Security
Date: 2013-01-02 17:19:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
> >
> >
> > 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>
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://

Remember to vote!
Consider donating to Postgres:

In response to


pgsql-hackers by date

Next:From: Fabrízio de Royes MelloDate: 2013-01-02 17:26:42
Subject: Re: Minor fix in 'clean' action of 'src/backend/Makefile'
Previous:From: Tom LaneDate: 2013-01-02 16:44:32
Subject: Re: [COMMITTERS] pgsql: Unify some tar functionality across different parts

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group