* Craig Ringer (craig@2ndquadrant.com) wrote:
> 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.
Yeah.
> 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.
No- if we were going to do this, I wouldn't want to change the existing
structure but rather provide either:
a) a way to simply disable RETURNING if the policy is in effect and the policy creator doesn't wish to allow it
b) allow the user to define another clause which would be applied to the rows in the RETURNING set
> 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.
Right- that consideration was one of the reasons to not mess with
RETURNING, in my view.
> 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.
I assume you mean with regard to documentation..? I'll work on
improving that.
Thanks!
Stephen
