From: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Greg Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, bogdan(at)omnidatagrup(dot)ro, David Fetter <david(at)fetter(dot)org>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SE-PostgreSQL and row level security |
Date: | 2009-02-17 02:54:24 |
Message-ID: | 499A26E0.8010008@ak.jp.nec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | KaiGai Kohei | 2009-02-17 03:03:53 | Re: SE-PostgreSQL and row level security |
Previous Message | KaiGai Kohei | 2009-02-17 02:30:24 | Re: SE-PostgreSQL and row level security |