On Fri, Jan 9, 2015 at 1:09 PM, Stephen Frost <sfrost@snowman.net> wrote:
> To flip it around a bit, I don't think we can avoid checking the
> *resulting* tuple from the UPDATE against the UPDATE policy.
We can avoid it - by not updating. What I'm suggesting is that an
enforcement occurs that is more or less equivalent to the enforcement
that occurs when the UPDATE path is taken, without it actually being
taken. I accept that that isn't perfect, but it has its advantages.
> 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?
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.
--
Peter Geoghegan