2012/5/24 Florian Pflug <fgp@phlo.org>:
>>> If we also apply the security policy to newer version of tuples on
>>> update and insert, one idea is to inject a before-row-(update|insert)
>>> trigger to check whether it satisfies the security policy.
>>> For same reason, the trigger should be executed at the end of
>>> trigger chain.
>>
>> It's not clear to me that there is any need for built-in server
>> functionality here. If the table owner wants to enforce some sort of
>> policy regarding INSERT or UPDATE or DELETE, they can already do that
>> today just by attaching a trigger to the table. And they can enforce
>> whatever policy they like that way. Before designing any new
>> mechanism, what's wrong with the existing one?
>
> Yeah, applying the security policy to the new row (for UPDATES
> and INSERTS) seems weird - the policy determines what you can see,
> not what you can store, which might be two different things.
>
> But the security policy should still apply to the old rows, i.e.
> you shouldn't be after to UPDATE or DELETE rows you cannot see, no?
>
The case of INSERT / DELETE are simple; All we need to apply is
checks on either new or old tuples.
In case of UPDATE, we need to check on the old tuple whether use can
see, and on the new tuple whether use can store them.
Indeed, these are different checks, however, it seems like a black hole
if the new tuple is allowed to write but no reader privileges.
I expect most use cases choose same policy on reader timing and
writer times at UPDATE statement.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>