On 16 December 2013 14:36, Craig Ringer <craig@2ndquadrant.com> wrote:
> - 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). I
> outlined the skeleton of a possible design in my earlier post, with the
> heirachical and non-heirachical access labels. Should be implemented
> using the same API we expose for extensions (like SEPostgresql RLS).
That part isn't clear why we "must" do better than that.
Having declarative security is a huge step forward, in just the same
way that updateable views were. They save the need for writing scripts
to implement things, rather than just having a useful default.
If there is a vision for that, lets see the vision. And then decide
whether its worth waiting for.
Personally, I see no reason not to commit the syntax we have now. So
people can see what we'll be supporting, whenever that is.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services