On Mon, Nov 4, 2013 at 8:46 PM, Craig Ringer <craig@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_jhtWc0fV2Q58NEgcxyTA@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
