On 16 December 2013 14:36, Craig Ringer <cr...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to