On 10/16/2014 01:44 PM, Craig Ringer wrote: > So the read-filtering policy should apply to all statements. Not just > SELECT.
Oh, IIRC one wrinkle in the prior discussion about this was that doing this will prevent the implementation of policies that permit users to update/delete rows they cannot otherwise see. That's an argument in favour of only applying a read-filtering policy where a RETURNING clause is present, but that introduces the "surprise! the effects of your DELETE changed based on an unrelated clause!" issue. Keep in mind, when considering RETURNING, that users don't always add this clause directly. PgJDBC will tack a RETURNING clause on the end of a statement if the user requests generated keys, for example. They will be very surprised if the behaviour of their DML changes based on whether or not they asked to get generated keys. To my mind having behaviour change based on RETURNING is actively wrong, wheras policies that permit rows to be updated/deleted but not selected are a nice-to-have at most. I'd really like to see some more coverage of the details of how these policies apply to inheritance, both the read- and write- sides of DML with RETURNING clauses, etc. -- Craig Ringer 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
