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

Etsuro,

* Etsuro Fujita (fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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