On 04/05/2014 03:57 AM, Andres Freund wrote: > c07) Updatable security barrier views. > This needs a serious look by a committer.
I've been exercising it via row security and it's been looking pretty solid. It isn't a huge or intrusive patch, and it's seen several rounds of discussion during its development and refinement. (Thanks Dean). In some ways it'd be nicer to do it by splitting resultRelation into two (row read source, and relation to write modified tuples into), but this turns out to be rather complex and exceedingly intrusive. We might need to do it someday - at that point, it wouldn't be overly hard to change updatable s.b. views over to working that way, but only once the major surgery required to remove the assumptions about resultRelation was done. Having this in place in 9.4 would allow people to build row-security like features in applications, and ease the path of row security into 9.5. > r04) Row-security based on Updatable security barrier views > This one's fate seems to be hard to judge without c07. Open issues remain with this patch, and resources for working on it in 9.4 have run out. It is not ready for commit. A core bugfix with locking in security barrier views is required before the regression tests can be fixed up properly, for one thing. Tom also expressed concerns about how plan invalidation works, though it's not yet clear whether that was just miscommunication about how it works on my part or whether there's a concrete problem there. I'd really love to finish this off for 9.4, but other projects have to come first. -- 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