On Wed, Sep 4, 2013 at 11:22 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> The same mechanism will prevent UPDATE and DELETE from seeing any rows >> the user shouldn't be able to touch. > > No, it won't, because we don't support direct update/delete on views > (and if you look, you'll notice the auto-updatable-view stuff doesn't > think a security-barrier view is auto-updatable). > > AFAICT, to deal with update/delete the RLS patch needs to constrain order > of qual application without the crutch of having a separate level of > subquery; and it's that behavior that I have zero confidence in, either > as to whether it works as submitted or as to our odds of not breaking it > in the future.
I don't really see why. AIUI, the ModifyTable node just needs to get the right TIDs. It's not like that has to be stacked directly on top of a scan; indeed, in cases like UPDATE .. FROM and DELETE .. USING it already isn't. Maybe there's some reason why the intervening level can be a Join but not a SubqueryScan, but if so I'd expect we could find some way of lifting that limitation without suffering too much pain. -- 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
