On Mon, Nov 4, 2013 at 8:46 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: > On 11/04/2013 11:17 PM, Robert Haas wrote: >> I'd still like to here what's wrong with what I said here: >> >> http://www.postgresql.org/message-id/ca+tgmoyr1phw3x9vnvuwdcfxkzk2p_jhtwc0fv2q58negcx...@mail.gmail.com > > For me, just my understanding. I'm still too new to the planner and > rewriter to grasp that properly as written. > > I was responding to Tom's objection, and he makes a good point about > CASE and optimisation. We have to be free to re-order and pre-evaluate > where LEAKPROOF flags make it safe and permissible, without ever > otherwise doing so. That makes the SECURITY BARRIER subquery look > better, since the limited pull-up / push-down is already implemented there. > > Robert, any suggesitons on how to approach what you suggest? I'm pretty > new to the planner's guts, but I know there've been some complaints > about the way the current RLS code fiddles with Vars when it changes a > direct scan of a rel into a subquery scan. > > The code in: > > https://github.com/ringerc/postgres/blob/rls-9.4/src/backend/optimizer/prep/prepunion.c#L1647 > > and > > https://github.com/ringerc/postgres/blob/rls-9.4/src/backend/optimizer/prep/prepunion.c#L1591 > > seems to be the one folks were complaining about earlier.
I haven't studied this patch in detail, but I see why there's some unhappiness about that code: it's an RLS-specific kluge. Just shooting from the hip here, maybe we should attack the problem of making security-barrier views updatable first, as a separate patch. I would think that if we make that work, this will also work without, hopefully, any special hackery. And we'd get a separate, independently useful feature out of it, too. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
