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

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...".

Regards,
Dean