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: http://www.postgresql.org/mailpref/pgsql-hackers