On Mon, Feb 16, 2009 at 11:43 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> I'm a little bothered by this issue with respect to INSERT, UPDATE, >> and DELETE, since it's possible that I have permission to see rows but >> not updated them, and it would be a little weird if select and update >> with equivalent where clauses operated on different sets of records >> (although that can happen anyway, because of BEFORE triggers, and it's >> pretty irritating). It's not clear that there's a clean solution >> here, but it's at least food for thought. > > 80% of the problem here is exactly that the proposed solution doesn't > seem very semantically clean. And once we accept it we're going to be > stuck with it for a long time --- compare for instance the multiple > serious annoyances with RULEs, which we can't fix easily because of > backwards compatibility considerations.
I've found rules in their current form to be nearly useless, except for views, which are wonderful. I do everything else with triggers. With reference to row-level security, most of the complaining about this feature has been along the lines of "I don't like the idea that rows get filtered from my result-set that I didn't ask to have filtered". To me, the fact that you didn't have to ask seems like a huge convenience, and I can't imagine why you'd want it otherwise. Sure, the behavior needs to be documented, but that doesn't seem like a big deal. There may well be more substantive issues here but I've been following this discussion fairly closely and I don't have a clear understanding of what they are. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
