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

Etsuro,

* Etsuro Fujita (fujita.etsuro@lab.ntt.co.jp) wrote:
> On 2015/02/11 4:06, Stephen Frost wrote:
> >* Etsuro Fujita (fujita.etsuro@lab.ntt.co.jp) wrote:
> >>On 2015/02/10 7:23, Dean Rasheed wrote:
> >>>Sorry, I didn't have time to look at this properly. My initial thought
> >>>is that expand_security_qual() needs to request a lock on rows coming
> >>>from the relation it pushes down into a subquery if that relation was
> >>>the result relation, because otherwise it won't have any locks, since
> >>>preprocess_rowmarks() only adds PlanRowMarks to non-target relations.
> >>
> >>That seems close to what I had in mind; expand_security_qual() needs
> >>to request a FOR UPDATE lock on rows coming from the relation it
> >>pushes down into a subquery only when that relation is the result
> >>relation and *foreign table*.
> >
> >I had been trying to work out an FDW-specific way to address this, but I
> >think Dean's right that this should be addressed in
> >expand_security_qual(), which means it'll apply to all cases and not
> >just these FDW calls.  I don't think that's actually an issue though and
> >it'll match up to how SELECT FOR UPDATE is handled today.
>
> Sorry, my explanation was not accurate, but I also agree with Dean's
> idea.  In the above, I just wanted to make it clear that such a lock
> request done by expand_security_qual() should be limited to the case
> where the relation that is a former result relation is a foreign
> table.

We aren't doing that for the other cases and so I don't think it makes
sense to do it here..  These should all be handled the same way.

> If it's OK, I'll submit a patch for that, maybe early next week.

Not really necessary, I have the code for it, just need to test, etc.
Thanks!
    Stephen