Re: WIP patch (v2) for updatable security barrier views - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: WIP patch (v2) for updatable security barrier views
Date
Msg-id 52EB6D34.4060005@2ndquadrant.com
Whole thread Raw
In response to Re: WIP patch (v2) for updatable security barrier views  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
On 01/31/2014 05:09 PM, Dean Rasheed wrote:
> I don't like this fix --- you appear to be adding another RTE to the
> rangetable (one not in the FROM list) and applying the rowmarks to it,
> which seems wrong because you're not locking the right set of rows.
> This is reflected in the change to the regression test output where,
> in one of the tests, the ctids for the table to update are no longer
> coming from the same table. I think a better approach is to push down
> the rowmark into the subquery so that any locking required applies to
> the pushed down RTE --- see the attached patch.

Thankyou.

I wasn't able to detect any changes in behaviour caused by the original
change other than the table alias change due to the additional RTE. The
new RTE referred to the same Relation, and there didn't seem to be any
problems caused by that.

Nonetheless, your fix seems a lot cleaner, especially in the target-view
case.

I've updated the commitfest app to show this patch.

> Anyway, please test if this works with your RLS code.

It does. Thankyou.

I'm still working on the other issues I outlined yesterday, but that's
for the other thread.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Dilip kumar
Date:
Subject: Re: [bug fix] psql \copy doesn't end if backend is killed
Next
From: Andres Freund
Date:
Subject: Re: Patch: show xid and xmin in pg_stat_activity and pg_stat_replication