From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, 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 20:43:57 |
Message-ID: | CAM3SWZQt-GaTRMbmrC5Xxx+QHzePhRtA1_kuh4d7beFRtaQUVA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 9, 2015 at 2:22 AM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> Whoa, hang on. I think you're being a bit quick to dismiss that
> example. Why shouldn't I want an upsert where the majority of the
> table columns follow the usual "make it so" pattern of an upsert, but
> there is also this kind of audit column to be maintained? Then I would
> write something like
>
> INSERT INTO tbl (<some values>, 0)
> ON CONFLICT UPDATE SET <same values>, mod_count=mod_count+1;
>
> The root of the problem is the way that you're proposing to combine
> the RLS policies (using AND), which runs contrary to the way RLS
> policies are usually combined (using OR), which is why this kind of
> example fails -- RLS policies in general aren't intended to all be
> true simultaneously.
In case I wasn't clear, I'm proposing that we AND together the already
OR'd together UPDATE and INSERT quals.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2015-01-09 20:46:01 | Re: Possible typo in create_policy.sgml |
Previous Message | Stephen Frost | 2015-01-09 20:26:07 | Re: INSERT ... ON CONFLICT UPDATE and RLS |