On 03/04/2014 09:41 PM, Yeb Havinga wrote: > On 04/03/14 02:36, Craig Ringer wrote: >> >> I've pushed an update to the branch with the fix for varno handling. >> Thanks. It's tagged rls-9.4-upd-sb-views-v8 . >> >> I've almost run out of time to spend on row security for this >> commitfest, unfortunately. I'm putting a blog together with a current >> status update. Frustrating, as it's coming together now. >> >> Open issues include: >> >> - Passing plan inval items from rewriter into planner >> - COPY support pending >> - Clear syntax in DDL >> >> Most of the rest are solved; it's actually looking pretty good. > > Hi Craig, > > I've tested the results from the minirim.sql that was posted earlier, > and the v8 gives the same results as v4 :-)
Good to hear. The main known issue remaining is plan invalidation. Row security needs to create PlanInvalItems during _rewrite_ and also needs to set a PlannerGlobal field for the user ID the plan depends on. If it fails to do this then the superuser will sometimes run queries and have row-security applied, non-superusers might skip row security when it should be applied. This seems to be the cause of foreign key check issues I've observed, too. That's not trivial, because right now the rewriter only returns a Query node. It doesn't have anywhere to stash information that's global across the whole query, and adding fields to Query for the purpose doesn't seem ideal, since it's also used for subqueries, and in the planner. Changing the rewriter to return a RewriteResult struct that contains the Query and some other global info would be very intrusive, though, as it'd affect all the plan cache and invalidation machinery and the various rewriter/planner call sites. I've also got some concerns about the user visible API; I'm not sure it makes sense to set row security policy for row reads per-command in PostgreSQL, since we have the RETURNING clause. Read-side policy should just be "FOR READ". Initially I think we should be using triggers to enforce write side policy, which should raise errors if you try to insert/update/delete the wrong thing. Could move to something working a bit more like WITH CHECK OPTION later. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers