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

Etsuro,

* Etsuro Fujita (fujita.etsuro@lab.ntt.co.jp) wrote:
> On 2015/02/18 7:44, Stephen Frost wrote:
> >Attached is a patch which should address this.  Would love your (or
> >anyone else's) feedback on it.  It appears to address the issue which
> >you raised and the regression test changes are all in-line with
> >inserting a LockRows into the subquery, as anticipated.
>
> I've looked into the patch.
>
> * The patch applies to the latest head, 'make' passes successfully,
> but 'make check' fails in the rowsecurity test.

Apologies for not being clear- the patch was against 9.4, where it
passes all the regression tests (at least for me- if you see
differently, please let me know!).

> * I found one place in expand_security_qual that I'm concerned about:
>
> +            if (targetRelation)
> +                applyLockingClause(subquery, 1, LCS_FORUPDATE,
> +                                   false, false);
>
> ISTM that it'd be better to use LockWaitBlock as the fourth argument
> of applyLockingClause.

LockWaitBlock isn't in 9.4. :)  Otherwise, I'd agree, and it's what I
plan to do for master.

> Other than that, the patch looks good to me.

Great, thanks!
Stephen