Re: row security roadmap proposal

On 12/16/13 9:36 AM, Craig Ringer wrote:
> - Finish and commit updatable security barrier views. I've still got a
> lot of straightening out to do there.
I don't follow why you've put this part first.  It has a lot of new 
development and the risks that go along with that, but the POC projects 
I've been testing are more interested in the view side issues.

> - Decide on and implement a structure for row-security functionality its
> self. I'm persuaded by Robert's comments here, that whatever we expose
> must be significantly more usable than a DIY on top of views (with the
> fix for updatable security barrier views to make that possible).

Can't say i agree we should be getting tangled into making this slick on 
the user side right now.  If you open a new can of worms like 
heirachical access labels, this goes back into basic design, and we'll 
spend months on that before returning to exactly the same implementation 
details.  I tried to make a case for how having a really generic 
mechanism that's doesn't presume to know how labels will be assigned can 
be a good thing.

Given the state this is all in right now, I'd much rather publish a hard 
to use but powerful API than to presume you're going to get an easier to 
use design right.  The place I'm at here is trying to figure out the 
simplest useful thing that could be committed and then hammer on the 
details.  (Not the first time I've beat that drum on a feature)  Your 
roadmap goes way past that, which is great to avoid being painted into a 
corner, but I'm thinking more about what a useful feature freeze point 
would look like given it's December 16 now.

-- 
Greg Smith greg.smith@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/