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
