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.sm...@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
