On 01/28/2014 12:09 AM, Simon Riggs wrote: > On 27 January 2014 15:04, Dean Rasheed <dean.a.rash...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
