Re: Odd behavior of updatable security barrier views on foreign tables - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Odd behavior of updatable security barrier views on foreign tables
Date
Msg-id 20150226023842.GD29780@tamriel.snowman.net
Whole thread Raw
In response to Re: Odd behavior of updatable security barrier views on foreign tables  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Responses Re: Odd behavior of updatable security barrier views on foreign tables  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers
Dean, Etsuro,

* Dean Rasheed (dean.a.rasheed@gmail.com) wrote:
> On 18 February 2015 at 16:22, Stephen Frost <sfrost@snowman.net> wrote:
> > Here's the patch against master.  I'm still fiddling with the comment
> > wording and the commit message a bit, but barring objections these
> > patches are what I'm planning to move forward with.
> >
>
> Yes, that matches what I had in mind.
>
> While you're tweaking comments, you might want to look at the comment
> in the block above which also relates to this new code, and says that
> "we will end up locking all rows which pass the securityQuals". That's
> not really accurate, I think it wants to say something like more like
> "we won't necessarily be able to push user-defined quals down into the
> subquery since they may include untrusted functions, and that means
> that we may end up locking rows that don't pass the user-defined
> quals.  In the worst case, we may end up locking all rows which pass
> the securityQuals...".

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!
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: "Ratay, Steve"
Date:
Subject: Re: Unable to build pg_rewind
Next
From: Peter Eisentraut
Date:
Subject: Re: CATUPDATE confusion?