From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: INSERT ... ON CONFLICT UPDATE and RLS |
Date: | 2015-01-09 21:02:41 |
Message-ID: | CAM3SWZTwXSOLzyMot0chABoCktFgZR676D93LXWyasC4_+oWuQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 9, 2015 at 12:53 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> I'm not sure how that would work exactly though, since the tuple the
> UPDATE results in might be different from what the INSERT has, as Dean
> pointed out. The INSERT tuple might even pass the UPDATE policy where
> the resulting tuple from the actual UPDATE part doesn't.
I'm not suggesting that Dean's example is totally without merit (his
revised explanation made it clearer what he meant). I just think, on
balance, that enforcing all INSERT + UPDATE policies at various points
is the best behavior. Part of the reason for that is that if you ask
people how they think it works, you'll get as many answers as the
number of people you ask. My proposal (which may or may not be the
same as yours, but if not is only slightly more restrictive) is
unlikely to affect many users negatively, and is relatively easy to
explain and reason about. There are workarounds for Dean's case, too.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-01-09 21:09:20 | Re: INSERT ... ON CONFLICT UPDATE and RLS |
Previous Message | Peter Geoghegan | 2015-01-09 20:53:22 | Re: INSERT ... ON CONFLICT UPDATE and RLS |