| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Rod Taylor <rod(dot)taylor(at)gmail(dot)com> |
| Cc: | Joe Conway <mail(at)joeconway(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Row Level Security UPDATE Confusion |
| Date: | 2017-04-17 19:51:01 |
| Message-ID: | 20170417195101.GD9812@tamriel.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Rod,
* Rod Taylor (rod(dot)taylor(at)gmail(dot)com) wrote:
> Yep. It's equivalent to a DELETE or DEACTIVATE. RLS may not be the right
> facility but it was very close to working exactly the way I wanted in FOR
> ALL mode.
Turning an UPDATE into, effectively, a DELETE, does seem like it's
beyond the mandate of RLS. Using an on-delete trigger strikes me as a
good approach.
The base premise of not allowing rows to be 'given away', similar to how
we don't allow full objects to be given away, should be enforced for the
'ALL' policy case, just as it is for the individual-command case. I'll
get that addressed before the next set of minor releases and will also
see about improving the documentation and code comments to make it more
clear.
Thanks!
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2017-04-17 19:54:41 | Re: SUBSCRIPTIONS and pg_upgrade |
| Previous Message | Tom Lane | 2017-04-17 19:43:09 | Re: Self-signed certificate instructions |