Re: Odd behavior of updatable security barrier views on foreign tables

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org >> PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Odd behavior of updatable security barrier views on foreign tables
Date: 2015-03-01 17:20:55
Message-ID: CAEZATCVHo+u8bgV2PF106o8FDLtoUJL7KSYTnyUbRGtnRuZHgg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27 February 2015 at 03:10, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> On 2015/02/26 11:38, Stephen Frost wrote:
>>
>> I've pushed an update for this to master and 9.4 and improved the
>> comments and the commit message as discussed.
>>
>> Would be great if you could test and let me know if you run into any
>> issues!
>

I just spotted a trivial bug in this patch -- in
expand_security_quals() you need to set targetRelation = false inside
the loop, otherwise it will be true for the target relation and all
that follow it. That was why the regression test output from
rls.v4.patch on the other thread wasn't what I expected.

Regards,
Dean

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2015-03-01 17:22:41 Re: Odd behavior of updatable security barrier views on foreign tables
Previous Message Simon Riggs 2015-03-01 16:27:33 Re: pgsql: Invent a memory context reset/delete callback mechanism.