On 01/28/2014 12:09 AM, Simon Riggs wrote:
> On 27 January 2014 15:04, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
>> So for example, when planning the query to update an inheritance
>> child, the rtable will contain an RTE for the parent, but it will not
>> be referenced in the parse tree, and so it will not be expanded while
>> planning the child update.
>
> Am I right in thinking that we have this fully working now?
I haven't found any further problems, though I've been focusing more on
reworking RLS on top of it.
> 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).
> We have long had restrictions around updateable views. My suggestion
> from here is that we accept the restriction that we cannot yet have
> the 3-way combination of updateable views, security views and views on
> inherited tables.
That prevents the use of updatable security barrier views over
partitioned tables, and therefore prevents row-security use on inherited
tables.
That seems like a very big thing to close off. I'm perfectly happy
having that limitation for 9.4, we just need to make it possible to
remove the limitation later.
> Most people aren't using inherited tables
Again, because we (ab)use them for paritioning, I'm not sure they're as
little-used as I'd like.
> and people that are have
> special measures in place for their apps. We won't lose much by
> accepting that restriction for 9.4 and re-addressing the issue in a
> later release.
Yep, I'd be happy with that.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services