Hi all I'm having a hard time seeing any reasonable semantics for the combination of row-security and inheritance in 9.4 that are also practical to implement.
I'm considering just punting on inheritance for 9.4, adding checks to prohibit inheritance from being added to a rel with row security and prohibiting any rel with inheritance from being given a row-security policy. Here's why: Detail ---- Earlier discussions seemed to settle on each relation having its own row-security quals applied independently. So quals on a parent rel did not cascade down to child rels. That gives you a consistent view of the data in a child rel when querying via the parent vs directly, which is good. It's surprising when you query via the parent and see rows the parent's row-security qualifier doesn't permit, but that surprising behaviour is consistent with other surprising things in inheritance, like a primary key on the parent not constraining rows inserted into children. The trouble is that this isn't going to work when applying row-security rules using the security barriers support. Security quals get expanded before inheritance expansion so that they're copied to all child rels. Just what you'd expect when querying a relation that's a parent of an inheritance tree via a view. It's what you'd expect to happen when querying a parent rel with row-security, too. Parent quals are applied to children. But that then gives you an inconsistent view of a rel's contents based on whether you query it via a parent or directly. I embarked upon that because of the concern that was expressed here about the way KaiGai's row-security patch fiddles directly with remapping attributes during planning; rebuilding row-security on top of updatable security barrier views was seen as a cleaner approach. So. I could: 1. Prohibit (in CREATE TABLE ... INHERITS, ALTER TABLE ... INHERITS, and ALTER TABLE ... SET ROW SECURITY) any parent or child rel from having row-security policy, i.e. punt it until 9.5; 2. Do another round of security qual expansion that fetches quals from pg_rowsecurity *after* inheritance expansion, giving us the each-relation-stands-alone behaviour; 3. Accept the inconsistent view of child rel contents in exchange for the otherwise sane behaviour of applying a parent's quals to children; document that if you don't want this, don't grant users direct access to the child tables; 4. attempt to pull quals from parents when querying a child rel directly. I'm going to have a go at making (2) happen, but if it doesn't come together fast, I'll just prohibit the combination of inheritance and row-security for 9.4. That won't upset updatable security barrier views, only actual row-security policy. People who want row-security over partitioned tables will just have to be patient. -- Craig Ringer 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
