Re: INSERT ... ON CONFLICT UPDATE and RLS

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

In response to

Browse pgsql-hackers by date

  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