On 28 January 2014 04:10, Kouhei Kaigai <kaigai@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