On Wed, Jan 02, 2013 at 05:35:13PM +0100, Kohei KaiGai wrote: > 2012/12/31 Simon Riggs <si...@2ndquadrant.com>: > > On 23 December 2012 18:49, Simon Riggs <si...@2ndquadrant.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.
Great! 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? Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers