On Fri, Sep 11, 2015 at 7:33 AM, Stephen Frost <sfr...@snowman.net> wrote: > I've updated the page to add more details about the various items, > though the only code changes at this point considered 'open' are this > refactoring and the question regarding the 'row-level-security disabled' > context which I posted a patch for discussion yesterday. > > Comments and help on these would certainly be welcome, of course. We're > working on a set of documentation updates to hopefully finish up in the > next week to add more details about RLS (additional sub-sections, > coverage of the issue Peter raised, additional discussion of RETURNING, > etc).
Thanks for the updates. My thoughts: On RETURNING, it seems like we've got a fairly fundamental problem here. If I understand correctly, the intention of allowing policies to be filtered by command type is to allow blind updates and deletes, but this behavior means that they are not really blind. You can always use BEGIN/UPDATE-or-DELETE-with-RETURNING/ROLLBACK as a substitute for SELECT. So the only possible thing you can do with the ability to filter by command tag that is coherent from a security point of view is to make the update and delete predicates *tighter* than the select predicate. And if that's where we end up, then haven't we fundamentally mis-designed the feature? I mean, without the blind update case, it just seems kooky to have different commands see different rows. It would be better to have all the command see the same rows, and then have update/delete *error out* if you try to update a row you're not allowed to touch. On Dean's refactoring patch, I would tend to favor back-patching whatever do there to 9.5, but I'm not volunteering to do the work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers