Re: ON CONFLICT issues around whole row vars,

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ON CONFLICT issues around whole row vars,
Date: 2015-10-01 23:19:57
Message-ID: CAM3SWZSPUxA9CP3m_kVti8USemV6XZsQz0mi33yEAQiLQt02+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 1, 2015 at 3:53 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> I specifically remember discussing this with you off list (on IM,
>> roughly a couple of weeks prior to initial commit). I recommended that
>> we err towards a more restrictive behavior in the absence of any
>> strong principle pushing us one way or the other. You seemed to agree.
>
> I don't think this really is comparable. Comparing this with a plain
> INSERT or UPDATE this would be akin to running RLS on the RETURNING
> tuple - which we currently don't.
>
> I think this is was just a bug.

Maybe that's the problem here; I still thought that we were planning
on changing RLS in this regard, but it actually seems we changed
course, looking at the 9.5 open items list.

I would say that that's a clear divergence between RLS and column
privileges. That might be fine, but it doesn't match my prior
understanding of RLS (or, more accurately, how it was likely to change
pre-release).

If that's the design that we want for RLS across the board, then I'm
happy to defer to that decision.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2015-10-01 23:26:07 Re: ON CONFLICT issues around whole row vars,
Previous Message Michael Paquier 2015-10-01 23:19:53 Re: pg_dump LOCK TABLE ONLY question