| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Greg Stark <stark(at)enterprisedb(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, 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-16 16:43:59 |
| Message-ID: | 18072.1234802639@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.
80% of the problem here is exactly that the proposed solution doesn't
seem very semantically clean. And once we accept it we're going to be
stuck with it for a long time --- compare for instance the multiple
serious annoyances with RULEs, which we can't fix easily because of
backwards compatibility considerations.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-02-16 17:18:21 | Re: SE-PostgreSQL and row level security |
| Previous Message | Robert Haas | 2009-02-16 16:39:09 | Re: SE-PostgreSQL and row level security |