> > 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)?
Thanks, -- NEC OSS Promotion Center / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com> > -----Original Message----- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer > Sent: Tuesday, January 28, 2014 12:35 PM > To: Simon Riggs; Dean Rasheed > Cc: Kaigai, Kouhei(海外, 浩平); Tom Lane; PostgreSQL Hackers; Kohei KaiGai; > Robert Haas > Subject: Re: [HACKERS] WIP patch (v2) for updatable security barrier views > > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
