Peter,
* Peter Geoghegan (pg@heroku.com) wrote:
> On Fri, Jan 9, 2015 at 2:22 AM, Dean Rasheed <dean.a.rasheed@gmail.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.
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.
Thanks!
Stephen
