Robert Haas wrote:
> I'm a little bothered by this issue with respect to INSERT, UPDATE,
> and DELETE, since it's possible that I have permission to see rows but
> not updated them, and it would be a little weird if select and update
> with equivalent where clauses operated on different sets of records
> (although that can happen anyway, because of BEFORE triggers, and it's
> pretty irritating). It's not clear that there's a clean solution
> here, but it's at least food for thought.
When user tries to INSERT, UPDATE or DELETE tuples without enough
privileges, the current row-level feature filters out violated tuples
from the affected set.
This behavior is same as when BEFORE-ROW trigger returns NULL.
If the given query requires both of SELECT and UPDATE permissions,
only tuples with both of permissions are affected, like:
UPDATE t SET a = 1, b = 'aaa' RETURNING *;
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>