On Fri, Sep 11, 2015 at 10:49 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dean Rasheed <dean.a.rash...@gmail.com> writes: >> Yeah, we had a similar discussion regarding UPDATE USING policies and >> ON CONFLICT UPDATE clauses. I think the argument against filtering is >> that the rows returned would then be misleading about what was >> actually updated. > > It seems to me that it would be a horribly bad idea to allow RLS to act > in such a way that rows could be updated and then not shown in RETURNING. > > However, I don't see why UPDATE/DELETE with RETURNING couldn't be > restricted according to *both* the UPDATE and SELECT policies, > ie if there's RETURNING then you can't update a row you could not > have selected. Note this would be a nothing-happens result not a > throw-error result, else you still leak info about the existence of > the row.
Yes, this seems like an entirely reasonable way forward. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
