* Peter Geoghegan (pg@heroku.com) wrote:
> On Fri, Jan 9, 2015 at 1:09 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > Therefore,
> > I'm not sure that I see the point in checking the INSERT tuple against
> > the UPDATE policy.
>
> I guess it wouldn't be hard to modify the struct WithCheckOption to
> store the cmd (e.g. RowSecurityPolicy-style ACL_*_CHR permissions),
> usable only in this context. That way, when ExecWithCheckOptions() is
> called from the INSERT, we can tell it to only enforce
> INSERT-applicable policy cmds (in particular, not
> UPDATE-only-applicable policy cmds that happen to end up associated
> with the same ResultRelation). Whereas, at the end of ExecUpdate(),
> that final ExecWithCheckOptions() call (call 3 of 3 when the UPDATE
> path is taken), INSERT-based policies can still be enforced against
> the final tuple (as can USING() quals that would ordinarily not be
> checked at that point either). A given ResultRelation's policies
> wouldn't necessarily always need to be enforced within
> ExecWithCheckOptions(), which is a change. Does that make sense to
> you?
That sounds reasonable on first blush. I'll note that I've not looked
deeply at the UPSERT patch, but if the above means that the INSERT
policy is always checked against the INSERT tuple and the UPDATE policy
is always checked against the tuple-resulting-from-an-UPDATE, and that
tuples which are not visible due to the UPDATE policy throw an error in
that case, then it's working as I'd expect.
This does mean that the UPDATE policy won't be checked when the INSERT
path is used but that seems appropriate to me, as we can't check a
policy against a tuple that never exists (the result of the update
applied to an existing tuple).
> Note that I've already taught ExecWithCheckOptions() to not leak the
> existing, target tuple when the UPDATE path is taken (the tuple that
> can be referenced in the UPDATE using the TARGET.* alias), while still
> performing enforcement against it. I can teach it this too.
Ok.
Thanks!
Stephen