On 20 December 2012 19:42, Stephen Frost <sfr...@snowman.net> wrote: > Kevin, all, > > * Kevin Grittner (kgri...@mail.com) wrote: >> The more secure behavior is to allow entry of data which will not >> be visible by the person doing the entry. > > wrt this- I'm inclined to agree with Kevin. It's certainly common in > certain environments that you can write to a higher level than you can > read from. Granting those writers access to read the data later would > be... difficult. > > What we're really arguing about here, afaict, is what the default should > be. In line with Kevin's comments and Tom's reading of the spec (along > with my own experience in these environments), I'd argue for the default > to allow writing rows you're not allowed to read. > > It would certainly be ideal if we could support both options, on a > per-relation basis, when we release the overall feature. It doesn't > "feel" like it'd be a lot of work to do that, but I've not been able to > follow this discussion up til now. Thankfully, I'm hopeful that I'm > going to have more time now to keep up with PG. :)
It is certainly possible to deliver a row security feature that covers all the cases discussed in 9.3. I want that. 1. The case of "row security applies to all commands" is simple to implement and document, since it presents no anomalies. 2. As KaiGai has explained, there are significant anomalies in the behaviour of "row security applies only to reads". Those anomalies need to be analysed carefully. They also need to be explained to the user in documentation. It's unreasonable for people to demand a feature yet provide no guidance to the person trying (hard) to provide that feature in a sensible way. If people genuinely believe case (2) is worth pursuing, additional work and input is needed so that KaiGai can make changes in time for the 9.3 deadline. Please read what KaiGai has said and respond. Since there are so many people reading this thread and wanting (2), that seems reasonable to expect. What I have proposed is that I work on the review for case (1) and then if we solve (2) that can go in also. I don't think its reasonable to reject the whole feature because of unresolved difficulties around one use case, which is what will happen if this is seen as merely a debate about defaults. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers