On Wed, Nov 6, 2013 at 1:38 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: > (a) Updatable views are implemented in the rewriter, not the planner. > The rewriter is not re-run when plans are invalidated or when the > session authorization changes, etc. This means that we can't simply omit > the RLS predicate for superuser because the same rewritten parse tree > might get used for both superuser and non-superuser queries.
My impression was that we had discussed this problem with respect to some earlier version of the RLS patch and that the conclusion of that discussion was that we needed to record in the cached plan whether the plan was one which is sensitive to the user ID and, if so, avoid using that plan with a different user ID. I am murky on the details; I believe the original discussion of this topic was a year or more ago. > (b) Inheritance is a problem when RLS is done in the rewriter. As I > understood it from Kohei KaiGai's description to me earlier, there was a > strong preference on -hackers to enforce RLS predicates for child and > parent tables completely independently. Not to put a too fine a point on it, but I think that's a really bad plan; and I don't remember any such discussion. > That's how RLS currently works, > but it might be hard to get the same effect when applying RLS in the > rewriter. We'd need to solve that, or redefine RLS's behaviour so that > the predicate on a parent table applies to any child tables too. > Personally I'd prefer the latter. Yes, let's please redefine it. The goal here ought to be to make RLS work as smoothly as possible with the rest of the system, not to invent weird semantics that are both unlike what we do elsewhere - and difficult to implement, to boot. I thought the whole point of implementing security barrier views was that read-side RLS would work just the same way, not having randomly incompatible semantics. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
