On 28 January 2014 04:10, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: >> > AFAICS the only area of objection is the handling of inherited >> > relations, which occurs within the planner in the current patch. I can >> > see that would be a cause for concern since the planner is pluggable >> > and it would then be possible to bypass security checks. Obviously >> > installing a new planner isn't trivial, but doing so shouldn't cause >> > collateral damage. >> >> FWIW, I don't see any way _not_ to do that in RLS. If there are security >> quals on a child table, they must be added, and that can only happen once >> inheritance expansion happens. That's in the planner. >> >> I don't see it as acceptable to ignore security quals on child tables, and >> if we can't, we've got to do some work in the planner. >> >> (I'm starting to really loathe inheritance). >> > Let me ask an elemental question. What is the reason why inheritance > expansion logic should be located on the planner stage, not on the tail > of rewriter? > Reference to a relation with children is very similar to reference of > multiple tables using UNION ALL. Isn't it a crappy idea to move the > logic into rewriter stage (if we have no technical reason here)?
I agree that this is being seen the wrong way around. The planner contains things it should not do, and as a result we are now discussing enhancing the code that is in the wrong place, which of course brings objections. I think we would be best served by stopping inheritance in its tracks and killing it off. It keeps getting in the way. What we need is real partitioning. Other uses are pretty obscure and we should re-examine things. In the absence of that, releasing this updateable-security views without suppport for inheritance is a good move. It gives us most of what we want now and continuing to have some form of restriction is better than having a much greater restriction of it not working at all. -- 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
